ERP Implementations: It’s a Matter of Complexity

 

There are many factors to blame for implementation process’ inefficiency, however many of the factors can be associated with the complexity of the project itself, respectively of the application(s) involved. The problem of complexity can be addressed by either answering to complexity with complexity, building a complex team to handle the tasks, which is seldom feasible even if many organizations do it, respectively by simplifying the implementation process and/or the application.

In what concerns the project, the complexity starts with requirement’s elicitation, the iterative transformations they suffer until the final functional requirements document is finalized, their evaluation and mapping to features, respectively gap’s identification. It’s a complex task because it involves understanding the business as well the functionality available in the target system(s). Then comes the effort estimation, which, as the name suggests, is just a guess based on available historical numbers and/or experts’ opinion. High-level requirements are easier to manage than low-level requirements, however they allow for more gaps in understanding. The more detailed the specifications, the more they should help in the estimation process, though that’s the theory. A considerable number of factors can impact the process.

Even if there are standard activities in the implementation process, the number of resources involved from the customer as well from the partner(s) side makes the whole planning process a nightmare for any Project Manager, no matter how experienced he/she is.

Ideally, each member of the team should behave like a trooper, knowing by instinct when and what needs to be done, which are the expectations, etc. This might be close to expectation on the partner side as the resources more likely participated in similar projects, though there’s always a mix between levels of expertise, resources migrating between projects. Unfortunately, that’s seldom (never) the case on the customer side as the gap between reality and expectation is considerable.

Each team member requires a minimum of information/knowledge so he/she can perform the activities assigned. Moreover, the volume of coordination and cooperation is considerably higher than in other projects, complexity that increases with organization’s size and is inverse proportional with organization’s maturity in managing projects and implementation-related activities. There’s thus a minimum of initial communication needed, and furthermore communication needs to occur between the parties involved. Moreover, the higher the lack of cohesion between the parties, the higher the need for communication and this applies especially when multiple organizations are involved in the project.

The triple constraint of Project Management between scope, cost, and time, respectively on quality has an important impact on the project. Resources need to be available when the project needs them and, especially on the partner side, only when they are needed. The implementation project to be feasible for the partner, its resources must work on several projects in parallel or the timing must be perfect, that no waiting times are involved, respectively the effort is concentrated only when needed. Such precision is possible maybe at project’s beginning, though the further the project evolves, the more challenging becomes the coordination of resources. Similar considerations apply to the customer as well.

Thus, a more realistic expectation is to have resources available only at certain points in time, and the resources should be capable of juggling between projects, respectively between project and other activities. Prioritizing is a must, and sometimes the operations or other projects have higher priority. When the time is not available, resources need to compromise by reducing the level of quality.

On the other side, it would be great if most of the effort could be concentrated at the beginning of the project, the later interactions being minimal.  

Previous <<||>> Next

Performance Management: First Time Right (The Aim toward Operational Excellence)

 

Rooted in Six Sigma methodology as a step toward operational excellence, First Time Right (FTR) implies that any procedure is performed in the right manner the first time and every time. It equates to minimizing the waste in its various forms (inventory, motion, overprocessing, overproduction, waiting, transportation, defects). Like many quality concepts from the manufacturing industry, the concept was transported in the software development process as principle, process, goal and/or metric. Thus, it became part of Software Engineering, Project Management, Data Science, and any other similar endeavors whose outcome results in software products. 

Besides the quality aspect, FTR is rooted also in the economic imperative – the need to achieve something in the minimum amount of time with the minimum of effort. It’s about being efficient in delivering a product or achieving a given target. It can be associated with continuous improvement, learning and mastery, the aim being to encompass FTR as part of organization’s culture. 

Even if not explicitly declared, FTR lurks in each task planned. It seems that it became common practice to plan with the FTR in mind, however between this theoretical aim and practice there’s as usual an important gap. Unfortunately, planners, managers and even tasks' performers often forget that mistakes are made, that several iterations are needed to get the job done. It starts with the communication between people in clarifying the requirements and ends with the formal sign off. All the deviations from the FTR add up in the deviations between expected and actual effort, though probably more important are the deviations from the plan and all the consequences deriving from it. Especially in complex projects this adds up into a spiral of issues that can easily reinforce themselves. 

Many of the jobs that imply creativity, innovation, research or exploration require at least several iterations to get the job done and this is independent of participants’ professionalism and experience. Moreover, the more quality one needs, the higher the effort, the 80/20 being sometimes a good approximation of the effort needed. In extremis, aiming for perfection instead of excellence can make certain tasks a never-ending story. 

Achieving FTR requires practice - the more novelty, the higher the complexity, the communication or the synchronization needs, the more practice is needed. It starts with the individual to master the individual tasks and ends with the team, where communication, synchronization and other aspects need to be considered. The practice is usually achieved on hands-on work as part of the daily duties, project work, and so on. Unfortunately, it’s based primarily on individual experience, and seldom groomed in advance, as preparation for future tasks. That’s why sometimes when efficiency is needed in performing critical complex tasks, one also needs to consider the learning curve in achieving the required quality. 

Of course, many organizations demand from job applicants experience and, when possible, they hire people with experience, however the diversity, complexity and changing nature of tasks require further practice. This aspect is somehow recognized in the implementation in organizations of the various forms of DevOps, though how many organizations adopt it and enforce it on a regular basis? Moreover, a major requirement of nowadays businesses is to be agile, and besides the mere application of methodologies, being agile means to have also a FTR mindset. 

FTR starts with the wish for mastery at individual and team level and, with the right management attention, by allocating time for learning, self-development in the important areas, providing relevant feedback and building an infrastructure for knowledge sharing and harnessing, FTR can become part of organization’s culture. It’s up to each of us to do it!

Strategic Management: Between Value and Waste I (Introduction)

 

Independently on whether Lean Management is considered in the context of Manufacturing, Software Development (SD), Project Management (PM) or any other business-related areas, there are three fundamental business concepts on which the whole scaffolding of the Lean philosophies is built upon, namely the ones of value, value stream and waste. 

From an economic standpoint, value refers to the monetary worth of a product, asset or service (further referred as product) to an organization, while from a qualitative perspective, it refers to the perceived benefit associated with its usage. The value is thus reflected in the costs associated with a product’s delivery (producer’s perspective), respectively the price paid on acquiring it and the degree to which the product can fulfill a demand (customer’s perspective).

Without diving too deep into theory of product valuation, the challenges revolve around reducing the costs associated with a product’s delivery, respectively selling it to a price the customer is willing to pay for, typically to address a given set of needs. Moreover, the customer is willing to pay only for the functions that satisfy the needs a product is thought to cover. From this friction of opposing driving forces, a product is designed and valued.

The value stream is the sequence of activities (also steps or processes) needed to deliver a product to customers. This formulation includes value-added and non-value-added activities, internal and external customers, respectively covers the full lifecycle of products and/or services in whatever form it occurs, either if is or not perceived by the customers.  

Waste is any activity that consumes resources but creates no value for the customers or, generally, for the stakeholders, be it internal or external. The waste is typically associated with the non-added value activities, activities that don’t produce value for stakeholders, and can increase directly or indirectly the costs of products especially when no attention is given to it and/or not recognized as such. Therefore, eliminating the waste can have an important impact on products’ costs and become one of the goals of Lean Management. Moreover, eliminating the waste is an incremental process that, when put in the context of continuous improvement, can lead to processes redesign and re-engineering.

Taiichi Ohno, the ‘father’ of the Toyota Production System (TPS), originally identified seven forms of waste (Japanese: muda): overproduction, waiting, transporting, inappropriate processing, unnecessary inventory, unnecessary/excess motion, and defects. Within the context of SD and PM, Tom and Marry Poppendieck [1] translated the types of wastes in concepts closer to the language of software developers: partially done work, extra processes, extra features, task switching, waiting, motion and, of course, defects. To this list were added later further types of waste associated with resources, confusion and work conditions.

Defects in form of errors and bugs, ineffective communication, rework and overwork, waiting, repetitive activities like handoffs or even unnecessary meetings are usually the visible part of products and projects and important from the perspective of stakeholders, which in extremis can become sensitive when their volume increases out of proportion.

Unfortunately, lurking in the deep waters of projects and wrecking everything that stands in their way are the other forms of waste less perceivable from stakeholders’ side: unclear requirements/goals, code not released or not tested, specifications not implemented, scrapped code, overutilized/underutilized resources, bureaucracy, suboptimal processes, unnecessary optimization, searching for information, mismanagement, task switching, improper work condition, confusion, to mention just the important activities associated to waste.

Through their elusive nature, independently on whether they are or not visible to stakeholders, they all impact the costs of projects and products when the proper attention is not given to them and not handled accordingly.

References:
[1] Mary Poppendieck & Tom Poppendieck (2003) Lean Software Development: An Agile Toolkit, Addison Wesley, ISBN: 0-321-15078-3

ERP Implementations: It’s all about Planning

Ideally the total volume of work can be uniformly distributed for all project’s duration though in praxis the curve representing the effort has the form of a wave or aggregation of waves that tend to reach the peak shortly before or during the Go-Live(s). More important, higher fluctuations occur in the various areas of the project on whole project’s duration, as there are dependencies between the various functional areas, as one needs to wait for decisions to be made, people are not available, etc. Typically, the time wasted on waiting, researching or other non-value-added activities have the potential of leading to such peaks. Therefore, the knowledge must be available, and decisions must be taken when required, which can be challenging but not impossible to achieve. 

To bridge the time wasted on waiting, the team members need to work on other topics. If on customer’s side the resources can handle maybe other activities, on vendor’s side the costs can be high and proportional with the volume of waiting. Therefore, vendor’s resources must be involved at least in two projects or do work in other areas in advance, which is not always possible. However, when vendor’s resources are involved in two or more projects, unless the planning is perfect or each resource can handle the work as it comes, there are further waiting times added. The customer is then forced either to book the resources exclusively, or to wait and carry the costs associated with it. 

On the other side ERP Implementations tend to become exploration projects, especially when the team has only partial knowledge about the system, or the requirements have a certain degree of specialization that deviates from the standard processes. The more unknowns an ERP implementation has, the more difficult is to plan. To be able to plan one must know the activities ahead, how long they take, and of course, one must adhere to the delivery dates, because each delay can have a cascading effect that can impact project’s schedule considerably. 

Probably the best approach to planning is to group the activities into packages and plan the packages, being in each subteam’s duty to handle the planning for each package, following to manage at upper level only the open issues, risks or opportunities. This shifts the burden from Project Manager’s shoulders within the project. Moreover, even if in theory the plan can consider each activity, it will become obsolete as soon it’s updated given the considerable volume of work requested to maintain it. Periodically, one can still revise the whole plan to identify opportunities and risks. What the team can do is to plan for a certain time interval (e.g. 4-6 weeks) and build from there. This allows focusing on the most important activities. 

To further shift the burden, activities like Data Migration, Data Cleaning or the integrations with third party systems should be treated when possible as subprojects. Despite having interdependencies with the main project (e.g. parameters, master data, decisions) and share same resources, they have their own schedule whose deadlines need to be aligned with main project’s milestones. 

Unless the team and business put all effort to respect the plan and, as long the plan is realistic, the initial plan can seldom be respected – it’s anyway just a sketch of the road ahead that can change as the project progresses – and this aspect needs to be understood by the business otherwise will lead to false expectations. On the other side, the team must try respecting the deadlines and communicate in time inability to do so. It’s an interplay in which communication is more important than ever.

Previous Post <<||>> Next Post

Graphical Representation: Graphics We Live by (Part V: Pie Charts in MS Excel)

From business dashboards to newspapers and other forms of content that capture the attention of average readers, pie charts seem to be one of the most used forms of graphical representation. Unfortunately, their characteristics make them inappropriate for displaying certain types of data, and of being misused. Therefore, there are many voices who advice against using them for any form of display.

It’s hard to agree with radical statements like ‘avoid (using) pie charts’ or ’pie charts are bad’. Each form of graphical representation (aka graphical tool, graphic) has advantages and disadvantages, which makes it appropriate or inappropriate for displaying data having certain characteristics. In addition, each tool can be easily misused, especially when basic representational practices are ignored. Avoiding one representational tool doesn’t mean that the use of another tool will be correct. Therefore, it’s important to make people aware of these aspects and let them decide which tools they should use. 

From a graphical tool is expected to represent and describe a dataset in a small area without distorting the reality, while encouraging the reader to compare the different pieces of information, when possible at different levels of details [1] or how they change over time. As form of communication, they encode information and meaning; the reader needs to be able to read, understand and think critically about graphics and data – what is known as graphical/data literacy.

A pie chart consists of a circle split into wedge-shaped slices (aka edges, segments), each slice representing a group or category (aka component). It resembles with the spokes of a wheel, however with a few exceptions they are seldom equidistant. The size of each slice is proportional to the percentage of the component when compared to the whole. Therefore, pie charts are ideal when displaying percentages or values that can be converted into percentages. Thus, the percentages must sum up to 100% (at least that’s readers’ expectation).

Within or besides the slices are displayed components’ name and sometimes the percentages or other numeric or textual information associated with them (Fig. 1-4).  The percentages become important when the slices seem to be of equal sizes. As long the slices have the same radius, comparison of the different components resumes in comparing arcs of circles or the chords defined by them, thing not always straightforward. 3-dimensional displays can upon case make the comparison more difficult.

The comparison increases in difficulty with the number of slices increases beyond a certain number. Therefore, it’s not recommended displaying more than 5-10 components within the same chart. If the components exceed this limit, the exceeding components can be summed up within an “other” component. 

Within a graphic one needs a reference point that can be used as starting point for exploration. Typically for categorical data this reference point is the biggest or the smallest value, the other values being sorted in ascending, respectively descending order, fact that facilitates comparing the values. For pie charts, this would mean sorting the slices based on their sizes, except the slice for “others” which is typically considered last.

The slices can be filled optionally with meaningful colors or (hashing) patterns. When the same color pallet is used, the size can be reflected in colors’ hue, however this can generate confusion when not applied adequately. It’s recommended to provide further (textual) information when the graphical elements can lead to misinterpretations. 

Pie charts can be used occasionally for comparing the changes of the same components between different points in time, geographies (Fig. 5-6) or other types of segmentation. Having the charts displayed besides each other and marking each component with a characteristic color or pattern facilitate the comparison. 

Project Management: Planning Correctly Misundersood IV

The relatively big number of Project Management (PM) methodologies considered nowadays makes it more and more difficult to understand the world of PM and make oneself understood, in the context in which terminology is used in explanations that defy the logic, in which people are stubborn in persisting that their understanding is the ultimate truth and, that between white and black there are no degrees of gray. Between all PM concepts project planning seems to be the most misunderstood, and this probably because all the activities revolve around it, while each methodology brings its own planning philosophy. Each methodology comes with its own story, its own imaginative description of what a perfect plan is about.

Independently of the methodology used there are three levels of planning. At highest level, the strategic one, the project is put in the context of other strategic activities – other projects and initiatives, as well business operations, competing altogether for the same financial and human resources.  At this level are the goals identified and put the basis for the successful execution of the project, including establishing the ground and integrating the main aspects of a project – risk, quality and communication. Here is decided which projects will be considered, in which sequence, how and when resources will be assigned. 

A project plan is typically written and further executed by having the tactical horizon in mind – the individual engagement of resources and actions, the actual means to reach the objectives set at strategic level. It’s the level where the actual project plan is detailed, where activities are sequenced and prioritized. Here each methodology has its own approach – whether the planning is done per deliverable, work package or any other approach used to partition the activities. It’s the level at which the various teams are coordinated toward specific targets. Thus the manageable unit is the team and not the individual, the deliverables or the work packages and not the individual tasks.

The operational level equates with the execution of a project’s activities. Even if the project manager oversights the activities, it’s in team’s duties to plan the activities having the set deliveries in mind. The project manager doesn’t need to know all the details, though he should be updated on a timely manner on the progress, the eventual risks and opportunities that arise in each area. This requires continuous coordination on vertical as well horizontal level.

The project manager typically oscillates between the strategic and tactical views of a project, while the operational level appears in the view only when operational themes are escalated or further coordination is needed. Even if this delimitation is clear in big projects, in the small projects the three levels melt into each other. Therefore the sprung from small to big projects and vice-versa can create issues when the approach is not tailored to project’s size and its further characteristics.

Attempting to plan each activity in the project at the lowest level of detail obscures the view, the complexity of the project kicking back sooner or later. Maintaining such a detailed plan can become a waste of time on the long term. In extremis a resource is used to update a plan, which easily can become obsolete by the time all activities were reviewed. This doesn’t mean that the project plan doesn’t need to be updated regularly, though the pace can be decided on each project’s specifics.

Therefore, one of the most important challenges in projects is finding the appropriate level of detail for planning, and there’s no general rule that works for all projects. Typically the choices alternate between work packages and deliverables. 

Project Management: Some Thoughts on Planning I

One of the issues in Project Management (PM) planning is that the planner idealizes a resource and activities performed by it much like a machine. Unlike machines whose uptime can approach 100%, a human resource can work at most 90% of the available time (aka utilization time), the remaining 10% being typically associated with interruptions – internal emails and meetings, casual communications, pauses, etc. For resources split between projects or operations the utilization time can be at most 70%, however a realistic value is in general between 40% and 60% on average. What does it mean this for a project?

So, if a resource has a volume of work W, the amount of time needed to complete the work would be at best W/UT, where UT is the utilization time of the respective resource. “At best” because in each project there are additional idle time resulted from waste related activities – waiting for sign off, for information, for other resource to complete the time, etc.

The utilization time is not the only factor to consider. Upon case, the delivered work can reach maybe on average 80% of the expected quality. This applies to documentation and concepts as well for written code, bug testing and other project activities. To reach in the range of 100% one more likely will need 4 times of the effort associated with reaching 80% of the expected quality, however this value is dependent also on people’s professionalism and the degree with which the requirements were understood and possibly achievable. Therefore, the values vehiculated can be regarded as “boundary” values.

Let’s consider a quality factor (QF) which has a value of 1 for 80%, with an increase of 0,25 for each 5% of quality increase. Thus, with an initial effort estimation of 100 days, this is how the resulted effort modifies for various UT and QF values:

Considering that a project can target between 60% and 95% UT, and between 80% and 95% quality, for an initial estimation of 100 days the actual project duration can range between 117 and 292 days, where the lowest, respectively the right bound values are more realistic.

The model is simplistic as it doesn’t reflect the nonlinear aspect of the factors involved and the dependencies existing between them. It also doesn’t reflect the maturity of an organization to handle the projects and the tasks involved. However, it can be used to increase the awareness in how the utilization time and expected quality can affect a project’s timeline, and to check on whether one’s planning is realistic.

For example, at project’s start one can target an UT of 70% and a quality of 85%, which for 100 days of estimated effort will result in about 178 days of actual effort. Now diving the value by the number of resources involved, e.g. 4, it results that the project could be finished in about 44,5 days. This value can be compared then with the actual plan in which the activities are listed.

During the project it would be useful to look on how the UT changed and by how much, to understand the impact the change has on the project. For example, a decrease of 5% in utilization time can delay the project with 2,5 days which is not much, though for a project of 1000 days with talk already about one month. Same, it will be helpful to check how much the quality deviated from the expectation, because a decrease in quality by 5% can result in an additional effort of extra 8 days, which for 1000 days would mean almost 4 months of delay.

IT: Internet of Things (Definitions)

"A term used to describe the community or collection of people and items that use the Internet to communicate with other." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"The embedding of objects with sensors, coupled with the ability of objects to communicate, driving an explosion in the growth of big data." (Brenda L Dietrich et al, "Analytics Across the Enterprise", 2014)

"The Internet of Things entails the aim of all physical or uniquely identifiable objects being connected through wired and wireless networks. In this notion, every object would be virtually represented. Connecting objects in this way offers a whole new universe of possibilities. Real-time analysis of big data streams could enhance productivity and safety of systems (for example, roadways and cars being part of the Internet of Things could help to manage traffic flow). It can also make everyday life more convenient and sustainable (such as connecting all household devices to save electricity)." (Martin Hoegl et al, "Using Thematic Thinking to Achieve Business Success, Growth, and Innovation", 2014)

"IOT refers to a network of machines that have sensors and are interconnected enabling them to collect and exchange data. This interconnection enables devices to be controlled remotely resulting in process efficiencies and lower costs." (Saumya Chaki, "Enterprise Information Management in Practice", 2015)

"An interconnected network of physical devices, vehicles, buildings, and other items embedded with sensors that gather and share data." (Jonathan Ferrar et al, "The Power of People: Learn How Successful Organizations Use Workforce Analytics To Improve Business Performance", 2017)

"Ordinary devices that are connected to the Internet at any time, anywhere, via sensors." (Jason Williamson, "Getting a Big Data Job For Dummies", 2015)

"Also referred to as IoT. Term that describes the connectivity of objects to the Internet and the ability for these objects to send and receive data from each other." (Brittany Bullard, "Style and Statistics", 2016)

"computing or 'smart' devices often with ­sensor capability and the ability to collect, share, and transfer data using the Internet." (Daniel J. Power & Ciara Heavin, "Data-Based Decision Making and Digital Transformation", 2018)

"The wide-scale deployment of small, low-power computing devices into everyday devices, such as thermostats, refrigerators, clothing, and even into people themselves to continuously monitor health." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A network of physical objects that have, like cell phones and laptops, internet connectivity enabling automatic communication between them and any other machine connected to the internet without human intervention." (Sue Milton, "Data Privacy vs. Data Security", 2021)

"Integration of various processes such as identifying, sensing, networking, and computation." (Revathi Rajendran et al, "Convergence of AI, ML, and DL for Enabling Smart Intelligence: Artificial Intelligence, Machine Learning, Deep Learning, Internet of Things", 2021)

"It is an interdisciplinary field who is associated with the electronics and computer science. Electronics deals with the development of new sensors or hardware for IoT device and computer science deals with the development of software, protocols and cloud based solution to store the data generated form these IoT devices."  (Ajay Sharma, "Smart Agriculture Services Using Deep Learning, Big Data, and IoT", 2021)

"IoT is a network of real-world objects which consists of sensors, software, and other technologies to exchange data with the other systems over the internet." (Hari K Kondaveeti et al, "Deep Learning Applications in Agriculture: The Role of Deep Learning in Smart Agriculture", 2021)

"This refers to a system of inter-connected computing and smart devices, that are provided with unique identifiers and the ability to transfer data over a network without requiring human interaction." (Wissam Abbass et al, "Internet of Things Application for Intelligent Cities: Security Risk Assessment Challenges", 2021)

"describes the network where sensing elements such as sensors, cameras, and devices are increasingly linked together via the internet to connect, communicate and exchange information." (Accenture)

"ordinary devices that are connected to the internet at any time anywhere via sensors." (Analytics Insight)

"Technologies that enable objects and infrastructure to interact with monitoring, analytics, and control systems over internet-style networks." (Forrester)

IT: Interprocess Communication (Definitions)

"A method of letting threads and processes transfer data and messages among themselves; used to offer services to and receive services from other programs (for example, named pipes)." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A system by which threads and processes can transfer data and messages among themselves. Interprocess communication (IPC) is used to offer and receive services from other programs." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A mechanism through which operating system processes and threads exchange data and messages. IPCs include local mechanisms, such as Windows shared memory, or network mechanisms, such as Windows Sockets." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A mechanism of an operating system that allows processes to communicate with each other within the same computer or over a network." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"The ability of one task or process to communicate with another in a multitasking operating system. Common methods include pipes, semaphores, shared memory, queues, signals, and mailboxes." (Microsoft, "SQL Server 2012 Glossary", 2012)

"A tool designed for developers to allow communication and sharing of data between applications." (Mike Harwood, "Internet Security: How to Defend Against Attackers on the Web 2nd Ed.", 2015)

Software Engineering: Programming (Misconceptions about Programming II)

Continuation

One of the organizational stereotypes is having a big room full of cubicles filled with employees. Even if programmers can work in such settings, improperly designed environments restrict to a certain degree the creativity and productivity, making more difficult employees' collaboration and socialization. Despite having dedicated meeting rooms, an important part of the communication occurs ad-hoc. In open spaces each transient interruption can easily lead inadvertently to loss of concentration, which leads to wasted time, as one needs retaking thoughts’ thread and reviewing the last written code, and occasionally to bugs.

Programming is expected to be a 9 to 5 job with the effective working time of 8 hours. Subtracting the interruptions, the pauses one needs to take, the effective working time decreases to about 6 hours. In other words, to reach 8 hours of effective productivity one needs to work about 10 hours or so. Therefore, unless adequately planned, each project starts with a 20% of overtime. Moreover, even if a task is planned to take 8 hours, given the need of information the allocated time is split over multiple days. The higher the need for further clarifications the higher the chances for effort to expand. In extremis, the effort can double itself.

Spending extensive time in front of the computer can have adverse effects on programmers’ physical and psychical health. Same effect has the time pressure and some of the negative behavior that occurs in working environments. Also, the communication skills can suffer when they are not properly addressed. Unfortunately, few organizations give importance to these aspects, few offer a work free time balance, even if a programmer’s job best fits and requires such approach. What’s even more unfortunate is when organizations ignore the overtime, taking it as part of job’s description. It’s also one of the main reasons why programmers leave, why competent workforce is lost. In the end everyone’s replaceable, however what’s the price one must pay for it?

Trainings are offered typically within running projects as they can be easily billed. Besides the fact that this behavior takes time unnecessarily from a project’s schedule, it can easily make trainings ineffective when the programmers can’t immediately use the new knowledge. Moreover, considering resources that come and go, the unwillingness to invest in programmers can have incalculable effects on an organization performance, respectively on their personal development.

Organizations typically look for self-motivated resources, this request often encompassing organization’s whole motivational strategy. Long projects feel like a marathon in which is difficult to sustain the same rhythm for the whole duration of the project. Managers and team leaders need to work on programmers’ motivation if they need sustained performance. They must act as mentors and leaders altogether, not only to control tasks’ status and rave and storm each time deviations occur. It’s easy to complain about the status quo without doing anything to address the existing issues (challenges).

Especially in dysfunctional teams, programmers believe that management can’t contribute much to project’s technical aspects, while management sees little or no benefit in making developers integrant part of project's decisional process. Moreover, the lack of transparence and communication lead to a wide range of frictions between the various parties.

Probably the most difficult to understand is people’s stubbornness in expecting different behavior by following the same methods and of ignoring the common sense. It’s bewildering the easiness with which people ignore technological and Project Management principles and best practices. It resides in human nature the stubbornness of learning on the hard way despite the warnings of the experienced, however, despite the negative effects there’s often minimal learning in the process...

To be eventually continued…

Project Management: Agility under Eyeglasses I

There are more and more posts in the cyberspace voicing against the agile practices, the way they are understood and implemented by organizations. Some try to be hilarious [5]; others try to keep the scholastic seriousness [1] [2] [3] [4], and all of them make some valid points. In each remark there’re some seeds of truth, even if context-dependent.

Personally, I embrace an agile approach when possible, however I find it difficult to choose between the agile methodologies available on the market because each of them introduces some concepts that contradict what it means to be agile – to respond promptly to business needs. It doesn’t mean that one must consider each requirement, but that’s appropriate to consider those which have business justification. Moreover, organizations need to adapt the methodologies to their needs, and seldom vice-versa.

Considering the Agile Manifesto, it’s difficult to take as serious statements that lack precision, formulations like “we value something over something else” are more of a wish than principles. When people don’t understand what the agile “principles” mean, one occasionally hears statements like “we need no documentation”, “we need no project plan”, “the project plan is not important”, “Change Management doesn’t apply to agile projects” or “we need only high-level requirements because we’ll figure out where we’re going on the way”. Because of the lack of precision, a mocker can variate the lesser concept to null and keep the validity of the agile “principles”.

The agile approaches seem to lack control. If you’re letting the users in charge of the scope then you risk having a product that offers a lot though misses the essential, and thus unusable or usable to a lower degree. Agile works good for prototyping something to show to the users or when the products are small enough to easily fit within an iteration, or when the vendor wants to gain a customer’s trust. Therefore, agile works good with BI projects that combine in general all three aspects.

An abomination is the work in fix sprints or iterations of one or a few weeks, and then chopping the functionality to fit the respective time intervals. If you have the luck of having sign-offs and other activities that steal your time, then the productive time reduces up to 50% (the smaller the iterations the higher the percentage). What’s even unconceivable is that people ignore the time spent with bureaucracy. If this way of working repeats in each iteration then the project duration multiplies by a factor between 2 or 4, the time spent on Project Management increasing by the same factor. What’s not understandable is that despite bureaucracy the adherence to delivery dates, budget and quality is still required.

Sometimes one has the feeling that people think that software development and other IT projects work like building a house or like the manufacturing of a mug. You choose the colors, the materials, the dimensions and voila the product is ready. IT projects involve lot of unforeseen and one must react agilely to it. Here resides one of the most important challenges.   

Communication is one important challenge in a project especially when multiple interests are involved. Face-to-face conversation is one of the nice-to-have items on the wish list however in praxis isn’t always possible. One can’t expect that all the resources are available to meet and decide. In addition, one needs to document everything from meeting minutes, to Business Cases and requirements. A certain flexibility in changing the requirements is needed though one can’t change them arbitrarily, there must be a concept behind otherwise the volume of overwork can easily make the budget for a project explode exponentially.

||>> Next Post (continuation) 

Resources:
[1] Harvard Business Review (2018) Why Agile Goes Awry - and How to Fix It, by Lindsay McGregor & Neel Doshi (Online) Available from: https://hbr.org/2018/10/why-agile-goes-awry-and-how-to-fix-it
[2] Forbes (2012) The Case Against Agile: Ten Perennial Management Objections, by Steve Denning  (Online) Available from:
https://www.forbes.com/sites/stevedenning/2012/04/17/the-case-against-agile-ten-perennial-management-objections/#6df0e6ea3a95 
[3] Springer (2018) Do Agile Methods Work for Large Software Projects?, by Magne Jørgensen  (Online) Available from:
https://link.springer.com/chapter/10.1007/978-3-319-91602-6_12
[4] Michael O Church (2015) Why “Agile” and especially Scrum are terrible  (Online) Available from:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
[5] Dev.to (2019) Mockery of agile, by Artur Martsinkovskyi (Online) Available from: https://dev.to/arturmartsinkovskyi/mockery-of-agile-5bdf

Strategic Management: Defining the Strategy

In a previous post an organization’s strategy was defined as a set of coordinated and sustainable actions following a set of well-defined goals, actions devised into a plan and designed to create value and overcome an organization’s challenges. In what follows are described succinctly the components of the strategy.

A strategy’s definition should start with the identification of organization’s vision, where the organization wants to be in the future, its mission statement, a precise description of what an organization does in turning the vision from concept to reality, its values - traits and qualities that are considered as representative, and its principles – the guiding laws and truths for action. All these components have the purpose at defining at high-level the where (the vision), the why (the mission), the what (the core values) and by which means (the principles) of the strategy.

One of the next steps that can be followed in parallel is to take inventory of the available infrastructure: systems, processes, procedures, practices, policies, documentation, resources, roles and their responsibilities, KPIs and other metrics, ongoing projects and initiatives. Another step resumes in identifying the problems (challenges), risks and opportunities existing in the organization as part of a SWOT analysis adjusted to organization’s internal needs. One can extend the analysis to the market and geopolitical conditions and trends to identify further opportunities and risks. Within another step but not necessarily disconnected from the previous steps is devised where the organization could be once the problems, risks, threats and opportunities were addressed.

Then the gathered facts are divided into two perspectives – the “IS” perspective encompasses the problems together with the opportunities and threats existing in organization that define the status quo, while the “TO BE” perspective encompasses the wished state. A capability maturity model can be used to benchmark an organization’s current maturity in respect to industry practices, and, based on the wished capabilities, to identify organization’s future maturity.

Based on these the organization can start formulating its strategic goals – a set of long-range aims for a specific time-frame, from which are derived a (hierarchical) set of objectives, measurable steps an organization takes in order to achieve the goals. Each objective carries with it a rational, why the objective exists, an impact, how will the objective change the organization once achieved, and a target, how much of the objective needs to be achieved. In addition, one can link the objectives to form a set of hypothesis - predictive statements of cause and effect that involve approaches of dealing with the uncertainty. In order to pursue each objective are devised methods and means – the tactics (lines of action) that will be used to approach the various themes. It’s important to prioritize the tactics and differentiate between quick winners and long-term tactics, as well to define alternative lines of actions.

Then the tactics are augmented in a strategy plan (roadmap) that typically covers a minimum of 3 to 5 years with intermediate milestones. Following the financial cycles the strategy is split in yearly units for each objective being assigned intermediate targets. Linked to the plan are estimated the costs, effort and resources needed. Last but not the least are defined the roles, management and competency structures, with their responsibilities, competencies and proper level of authority, needed to support strategy’s implementation. Based on the set objectives are devised the KPIs used to measure the progress (success) and stir the strategy over its lifecycle.

By addressing all these aspects is created thus a first draft of the strategy that will need several iterations to mature, further changes deriving from the contact with the reality.

Governance: Authority (Just the Quotes)

"When the general is weak and without authority; when his orders are not clear and distinct; when there are no fixed duties assigned to officers and men, and the ranks are formed in a slovenly haphazard manner, the result is utter disorganization." (Sun Tzu, "The Art of War", cca. 5th century)

"Authority is never without hate." (Euripides, "Ion", cca. 422 BC)

"In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual" (Galileo Galilei, 1632)

"Authority without wisdom is like a heavy axe without an edge, fitter to bruise than polish." (Anne Bradstreet, "Meditations Divine and Moral", 1664)

"Lawful and settled authority is very seldom resisted when it is well employed." (Samuel Johnson, "The Rambler", 1750)

"The most absolute authority is that which penetrates into a man's innermost being and concerns itself no less with his will than with his actions." (Jean-Jacques Rousseau, "On the origin of inequality", 1755)

"The wise executive never looks upon organizational lines as being settled once and for all. He knows that a vital organization must keep growing and changing with the result that its structure must remain malleable. Get the best organization structure you can devise, but do not be afraid to change it for good reason: This seems to be the sound rule. On the other hand, beware of needless change, which will only result in upsetting and frustrating your employees until they become uncertain as to what their lines of authority actually are." (Marshall E Dimock, "The Executive in Action", 1915)

"No amount of learning from books or of listening to the words of authority can be substituted for the spade-work of investigation." (Richard Gregory, "Discovery; or, The Spirit and Service of Science", 1916)

"In organization it means the graduation of duties, not according to differentiated functions, for this involves another and distinct principle of organization, but simply according to degrees of authority and corresponding responsibility." (James D Mooney, "Onward Industry!", 1931)

"It is sufficient here to observe that the supreme coordinating authority must be anterior to leadership in logical order, for it is this coordinating force which makes the organization. Leadership, on the other hand, always presupposes the organization. There can be no leader without something to lead." (James D Mooney, "Onward Industry!", 1931)

"Leadership is the form that authority assumes when it enters into process. As such it constitutes the determining principle of the entire scalar process, existing not only at the source, but projecting itself through its own action throughout the entire chain, until, through functional definition, it effectuates the formal coordination of the entire structure." (James D Mooney, "Onward Industry!", 1931)

"The staff function in organization means the service of advice or counsel, as distinguished from the function of authority or command. This service has three phases, which appear in a clearly integrated relationship. These phases are the informative, the advisory, and the supervisory." (James D Mooney, "Onward Industry!", 1931)

"Human beings are compounded of cognition and emotion and do not function well when treated as though they were merely cogs in motion.... The task of the administrator must be accomplished less by coercion and discipline, and more and more by persuasion.... Management of the future must look more to leadership and less to authority as the primary means of coordination." (Luther H Gulick, "Papers on the Science of Administration", 1937)

"A person can and will accept a communication as authoritative only when four conditions simultaneously obtain: (a) he can and does understand the communication; (b) at the time of his decision he believes that it is not inconsistent with the purpose of the organization; (c) at the time of his decision, he believes it to be compatible with his personal interest as a whole; and (d) he is able mentally and physically to comply with it." (Chester I Barnard, "The Functions of the Executive", 1938)

"The fine art of executive decision consists in not deciding questions that are not now pertinent, in not deciding prematurely, in not making decision that cannot be made effective, and in not making decisions that others should make. Not to decide questions that are not pertinent at the time is uncommon good sense, though to raise them may be uncommon perspicacity. Not to decide questions prematurely is to refuse commitment of attitude or the development of prejudice. Not to make decisions that cannot be made effective is to refrain from destroying authority. Not to make decisions that others should make is to preserve morale, to develop competence, to fix responsibility, and to preserve authority.
From this it may be seen that decisions fall into two major classes, positive decisions - to do something, to direct action, to cease action, to prevent action; and negative decisions, which are decisions not to decide. Both are inescapable; but the negative decisions are often largely unconscious, relatively nonlogical, "instinctive," "good sense." It is because of the rejections that the selection is good." (Chester I Barnard, "The Functions of the Executive", 1938)

"To hold a group or individual accountable for activities of any kind without assigning to him or them the necessary authority to discharge that responsibility is manifestly both unsatisfactory and inequitable. It is of great Importance to smooth working that at all levels authority and responsibility should be coterminous and coequal." (Lyndall Urwick, "Dynamic Administration", 1942)

"All behavior involves conscious or unconscious selection of particular actions out of all those which are physically possible to the actor and to those persons over whom he exercises influence and authority." (Herbert A Simon, "Administrative Behavior: A Study of Decision-making Processes in Administrative Organization", 1947)

"Coordination, therefore, is the orderly arrangement of group efforts, to provide unity of action in the pursuit of a common purpose. As coordination is the all inclusive principle of organization it must have its own principle and foundation in authority, or the supreme coordination power. Always, in every form of organization, this supreme authority must rest somewhere, else there would be no directive for any coordinated effort." (James D Mooney, "The Principles of Organization", 1947)

"Delegation means the conferring of a specified authority by a higher authority. In its essence it involves a dual responsibility. The one to whom responsibility is delegated becomes responsible to the superior for doing the job. but the superior remains responsible for getting the Job done. This principle of delegation is the center of all processes in formal organization. Delegation is inherent in the very nature of the relation between superior and subordinate. The moment the objective calls for the organized effort of more than one person, there is always leadership with its delegation of duties." (James D Mooney, "The Principles of Organization", 1947)

"Power on the one side, fear on the other, are always the buttresses on which irrational authority is built." (Erich Fromm, "Man for Himself: An Inquiry Into the Psychology of Ethics", 1947)

"Authority is not a quality one person 'has', in the sense that he has property or physical qualities. Authority refers to an interpersonal relation in which one person looks upon another as somebody superior to him." (Erich Fromm, "The Fear of Freedom", 1950)

"The only way for a large organization to function is to decentralize, to delegate real authority and responsibility to the man on the job. But be certain you have the right man on the job." (Robert E Wood, 1951)

"[...] authority - the right by which superiors are able to require conformity of subordinates to decisions - is the basis for responsibility and the force that binds organization together. The process of organizing encompasses grouping of activities for purposes of management and specification of authority relationships between superiors and subordinates and horizontally between managers. Consequently, authority and responsibility relationships come into being in all associative undertakings where the superior-subordinate link exists. It is these relationships that create the basic character of the managerial job." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Although organization charts are useful, necessary, and often revealing tools, they are subject to many important limitations. In the first place, a chart shows only formal authority relationships and omits the many significant informal and informational relationships that exist in a living organization. Moreover, it does not picture how much authority exists at any point in the organization." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"[...] authority for given tasks is limited to that for which an individual may properly held responsible." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Authority delegations from a superior to a subordinate may be made in large or small degree. The tendency to delegate much authority through the echelons of an organization structure is referred tojas decentralization of authority. On the other hand, authority is said to be centralized wherever a manager tends not to delegate authority to his subordinates." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Authority is, of course, completely centralized when a manager delegates none, and it is possible to think of the reverse situation - an infinite delegation of authority in which no manager retains any authority other than the implicit power to recover delegated authority. But this kind of delegation is obviously impracticable, since, at some point in the organization structure, delegations must stop." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"If charts do not reflect actual organization and if the organization is intended to be as charted, it is the job of effective management to see that actual organization conforms with that desired. Organization charts cannot supplant good organizing, nor can a chart take the place of spelling out authority relationships clearly and completely, of outlining duties of managers and their subordinates, and of defining responsibilities." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"It is highly important for managers to be honest and clear in describing what authority they are keeping and what role they are asking their subordinates to assume." (Robert Tannenbaum & Warren H Schmidt, Harvard Business Review, 1958)

"Formal theories of organization have been taught in management courses for many years, and there is an extensive literature on the subject. The textbook principles of organization — hierarchical structure, authority, unity of command, task specialization, division of staff and line, span of control, equality of responsibility and authority, etc. - comprise a logically persuasive set of assumptions which have had a profound influence upon managerial behavior." (Douglas McGregor, 'The Human Side of Enterprise", 1960)

"If there is a single assumption which pervades conventional organizational theory, it is that authority is the central, indispensable means of managerial control." (Douglas McGregor, "The Human Side of Enterprise", 1960)

"The ingenuity of the average worker is sufficient to outwit any system of controls devised by management." (Douglas McGregor, "The Human Side of Enterprise", 1960)

"You can delegate authority, but you can never delegate responsibility by delegating a task to someone else. If you picked the right man, fine, but if you picked the wrong man, the responsibility is yours - not his." (Richard E Krafve, The Boston Sunday Globe, 1960)

"Centralized controls are designed to ensure that the chief executive can find out how well the delegated authority and responsibility are being exercised." (Ernest Dale, "Management: Theory and practice", 1965)

"In large-scale organizations, the factual approach must be constantly nurtured by high-level executives. The more layers of authority through which facts must pass before they reach the decision maker, the greater the danger that they will be suppressed, modified, or softened, so as not to displease the 'brass"' For this reason, high-level executives must keep reaching for facts or soon they won't know what is going on. Unless they make visible efforts to seek and act on facts, major problems will not be brought to their attention, the quality of their decisions will decline, and the business will gradually get out of touch with its environment." (Marvin Bower, "The Will to Manage", 1966)

"The concept of organizational goals, like the concepts of power, authority, or leadership, has been unusually resistant to precise, unambiguous definition. Yet a definition of goals is necessary and unavoidable in organizational analysis. Organizations are established to do something; they perform work directed toward some end." (Charles Perrow, "Organizational Analysis: A Sociological View", 1970)

"[Management] has authority only as long as it performs." (Peter F Drucker, "Management: Tasks, Responsibilities, Practices", 1973)

"'Management' means, in the last analysis, the substitution of thought for brawn and muscle, of knowledge for folkways and superstition, and of cooperation for force. It means the substitution of responsibility for obedience to rank, and of authority of performance for authority of rank. (Peter F Drucker, "People and Performance", 1977)

"The key to successful leadership today is influence, not authority." (Kenneth H Blanchard, "Managing By Influence", 1986)

"Strange as it sounds, great leaders gain authority by giving it away." (James B Stockdale, "Military Ethics" 1987)

"Perhaps nothing in our society is more needed for those in positions of authority than accountability." (Larry Burkett, "Business By The Book: Complete Guide of Biblical Principles for the Workplace", 1990)

"When everything is connected to everything in a distributed network, everything happens at once. When everything happens at once, wide and fast moving problems simply route around any central authority. Therefore overall governance must arise from the most humble interdependent acts done locally in parallel, and not from a central command. " (Kevin Kelly, "Out of Control: The New Biology of Machines, Social Systems and the Economic World", 1995)

"Authority alone is like pushing from behind. What automatic reaction do you have when pushed from behind? Resistance - unless you are travelling in that direction anyway and you experience the push as helpful. When you do not know what lies ahead and you are not sure whether you want to move forward, resistance is completely understandable. [...] Authority alone pushes. Leadership pulls, because it draws people towards a vision of the future that attracts them." (Joseph O’Connor, "Leading With NLP: Essential Leadership Skills for Influencing and Managing People", 1998)

"Authority works best where you have an accepted hierarchy [...]. Then people move together because of the strong implicit accepted values that everyone shares. If you are trying to lead people who do not share similar goals and values, then authority is not enough." (Joseph O’Connor, "Leading With NLP: Essential Leadership Skills for Influencing and Managing People", 1998)

"The ultimate authority must always rest with the individual's own reason and critical analysis." (Tenzin Gyatso, "Path To Tranquility", 1998)

"The premise here is that the hierarchy lines on the chart are also the only communication conduit. Information can flow only along the lines. [...] The hierarchy lines are paths of authority. When communication happens only over the hierarchy lines, that's a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"A system is a framework that orders and sequences activity within the organisation to achieve a purpose within a band of variance that is acceptable to the owner of the system.  Systems are the organisational equivalent of behaviour in human interaction. Systems are the means by which organisations put policies into action.  It is the owner of a system who has the authority to change it, hence his or her clear acceptance of the degree of variation generated by the existing system." (Catherine Burke et al, "Systems Leadership" 2nd Ed., 2018)

"Responsibility means an inevitable punishment for mistakes; authority means full power to make them." (Yegor Bugayenko, "Code Ahead", 2018)

"Control is not leadership; management is not leadership; leadership is leadership. If you seek to lead, invest at least 50% of your time in leading yourself–your own purpose, ethics, principles, motivation, conduct. Invest at least 20% leading those with authority over you and 15% leading your peers." (Dee Hock)

"Delegation of authority is one of the most important functions of a leader, and he should delegate authority to the maximum degree possible with regard to the capabilities of his people. Once he has established policy, goals, and priorities, the leader accomplishes his objectives by pushing authority right down to the bottom. Doing so trains people to use their initiative; not doing so stifles creativity and lowers morale." (Thornas H Moorer)

"Leadership means that a group, large or small, is willing to entrust authority to a person who has shown judgement, wisdom, personal appeal, and proven competence." (Walt Disney)

"The teams and staffs through which the modern commander absorbs information and exercises his authority must be a beautifully interlocked, smooth-working mechanism. Ideally, the whole should be practically a single mind." (Dwight D Eisenhower)

"While basic laws underlie command authority, the real foundation of successful leadership is the moral authority derived from professional competence and integrity. Competence and integrity are not separable." (William C Westmoreland)

Data Science: Data Storytelling (Definitions)

"A narrative way of describing a scenario, product idea, or strategy intended to provide a real-world context to promote decision making and better understanding." (Steven Haines, "The Product Manager's Desk Reference", 2008)

[storytelling:] "A method of communicating and sharing ideas, experiences and knowledge in a specific context." (Darren Dalcher, "Making Sense of IS Failures", Encyclopedia of Information Science and Technology 2nd Ed., 2009)

"A method of explaining a series of events through narrative." (Jonathan Ferrar et al, "The Power of People: Learn How Successful Organizations Use Workforce Analytics To Improve Business Performance", 2017)

"using a combination of data facts and a qualitative 'story' that provides effective communication of a business message." (Daniel J. Power & Ciara Heavin, "Data-Based Decision Making and Digital Transformation", 2018)

"Data storytelling can be defined as a structured approach for communicating data insights using narrative elements and explanatory visuals." (Brent Dykes, "Effective Data Storytelling: How to Drive Change with Data, Narrative and Visuals", 2019)

[storytelling:] "The social and cultural activity of sharing stories, with great application to journalism." (Georgios Vassis et al, "Review and Evaluation of Systems Supporting Data Journalism", 2021)

"Data storytelling forms a compelling narrative by putting data in context to show the challenges, insights and solutions of a specific business problem. It normally highlights a series of changes or trends over time through linked visualizations that combine to tell a story." (Sisense) [source]

"Data storytelling is a method of visually presenting data to make it more understandable and easy to digest. Visualizations such as charts and graphs guide users toward a conclusion about their data and empower them to make a decision based on that conclusion." (Logi Analytics) [source]

"Data storytelling is a methodology for communicating information, tailored to a specific audience, with a compelling narrative. It is the last ten feet of your data analysis and arguably the most important aspect." (Nugit) [source]

"Data storytelling is the practice of building a narrative around a set of data and its accompanying visualizations to help convey the meaning of that data in a powerful and compelling fashion." (TDWI)

Strategic Management: Organization Charts (Just the Quotes)

"The writer has found, in analyzing and diagnosing organization and accounting work, that charts can express more on one page than is sometimes expressed in several chapters of writing, and has been the author and originator of many methods of charting industrial expressions. It is necessary, as a first step, for analytical and other purposes, to make a chart expressing all of the relations governing the organization of a business so as to show the very foundation upon which all authorities, accounting, and business transactions are based and conducted. There have been more failures scored both personally and financially for lack of these very elements in a business than by reason of any other one thing. As well try to build a house without a foundation as to try to conduct a business, especially a manufacturing business, without proper organization." (Clinton E. Woods, "Organizing a factory", 1905)

"An Organization Chart is a cross section picture covering every relationship in the bank. It is a schematic survey showing department functions and interrelations, lines of authority, responsibility, communication and counsel. Its purpose is 'to bring the various human parts of the organization into effective correlation and co-operation'." (John W Schulze, "Office Administration", 1919)

"The frame work of the entire organization should be sketched, and the particular place in the scheme of things which his department and his position occupy should be explained. Almost any one can be shown a particular location on a map. An organization chart is a map." (John W Schulze, "Office Administration", 1919)

"The most elementary aspect of administration is organization the structure of social institutions and their constituent parts, the composition of economic enterprises and their various branches, the organization of governmental agencies and their numerous departments. As it is mainly a matter of structure, organization bears the same rudimentary relationship to administration as does the science of anatomy or skeletology to the field of medicine. An administrative organization can be sketched and charted just as the human body can be physically depicted. Apart from its graphic convenience and its 'teachable' quality, however, what intrinsic relationship does organization bear to administration?" (Albert Lepawsky, "Administration: the art and science of organization and management", 1949)

"Although organization charts are useful, necessary, and often revealing tools, they are subject to many important limitations. In the first place, a chart shows only formal authority relationships and omits the many significant informal and informational relationships that exist in a living organization. Moreover, it does not picture how much authority exists at any point in the organization." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Essential to organization planning, then, is the search for an ideal form of organization to reflect the basic goals of the enterprise. This entails not only charting the main lines of organization and reflecting the organizational philosophy of the enterprise leaders (e.g., shall authority be as centralized as possible, or should the company try to break its operations down into semiautonomous product or territorial divisions?), but also a sketching out of authority relationships throughout the structure." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"If charts do not reflect actual organization and if the organization is intended to be as charted, it is the job of effective management to see that actual organization conforms with that desired. Organization charts cannot supplant good organizing, nor can a chart take the place of spelling out authority relationships clearly and completely, of outlining duties of managers and their subordinates, and of defining responsibilities." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"One of the tools for making organization principles work is the organization chart. Any organization which exists can be charted, for a chart is nothing more than an indication of how departments are tied together along their principal lines of authority." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"Since a chart maps lines of authority, sometimes the mere charting of an organization will show inconsistencies and complexities and lead to their correction. A chart also acts as a guide for managers and new personnel in an organization, revealing how they tie into the entire structure. Charts are, therefore, not only evidences of organization planning but also road maps for decision making, and training devices for those who would learn how a company is organized." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"While good charting will attempt, as far as possible, to make levels on the chart conform to levels of importance in the business enterprise, it cannot always do so. This problem can be handled by clearly spelling out authority relationships." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"The relations outlined on an organization chart provide a framework within which fuller and more spontaneous human behavior takes place. The formal system may draw upon that behavior for added strength; it will in its turn be subordinated to personal and group egotism." (Philip Selznick, "Leadership in Administration: A Sociological Interpretation", 1957)

"It is probable that one day we shall begin to draw organization charts as a series of linked groups rather than as a hierarchical structure of individual 'reporting' relationships." (Douglas McGregor, "The Human Side of Enterprise", 1960)

"In some firms role relationships prescribed by the chart seemed to be of secondary importance to personal relationships between individuals. (Joan Woodward, "Industrial Organization: Theory and practice", 1965)

"Every organization structure, even a poor one, can be charted, for a chart merely indicates how departments are tied together along the principal lines of authority. It is therefore somewhat surprising to find top managers occasionally taking pride in the fact that they do not have an organization chart or, if they do have one, feeling that the chart should be kept a secret." (Harold Koontz, "Principles of management", 1968)

"[…] the organization chart will initially reflect the first system design, which is almost surely not the right one […] as one learns, he changes the design […]. Management structures also need to be changed as the system changes […]" (Fred Brooks, "The Mythical Man-Month: Essays on Software Engineering", 1975)

"An organization chart is a graphic device that uses pictorial methods to show qualitative information about an organization. [...] The organization chart can be used to show one or more of three things: (1) What the various staff positions in the organization are, how they are structurally related to each other and the span of control and chain of command within the organization. (2) What the different units of the organization are and how they are arranged and related to each other. (3) What the various functions are within the organization and how they are organized and related." (Robert Lefferts, "Elements of Graphics: How to prepare charts and graphs for effective reports", 1981)

"Every company has two organizational structures: the formal one is written on the charts; the other is the everyday living relationship of the men and women in the organization." (Harold Geneen & Alvin Moscow, "Managing", 1984)

"Organization charts and fancy titles count for next to nothing." (Colin Powell, "My American Journey", 1995)

"The premise here is that the hierarchy lines on the chart are also the only communication conduit. Information can flow only along the lines. [...] The hierarchy lines are paths of authority. When communication happens only over the hierarchy lines, that's a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Traditional organizational charts tend to institutionalize inefficiency, and misalignment of natural talents to job descriptions." (John Hoover, "Unleashing Leadership", 2005)

"Organization charts are subject to important limitations. A chart shows only formal authority relationships and omits the many significant informal and informational relationships." (Harold Koontz and Heinz Weihrich, "Essentials Of Management", 2006)

"When you accepted your job, you were not chosen solely to fill a position on the organization chart; you were chosen to fill a responsibility." (David Cottrell, "Monday Morning Mentoring: Ten Lessons to Guide You Up the Ladder", 2009)

"[…] decisions based on org-chart structure tend to optimize for only part of the organization, ignoring upstream and downstream effects. Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers. Their impact might be negligent if there are larger bottlenecks in the stream of work." (Matthew Skelton, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation while still delivering at a fast pace. In order to succeed at that, organizations need stable teams and effective team patterns and interactions. They need to invest in empowered, skilled teams as the foundation for agility and adaptability. To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly." (Matthew Skelton, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019