Overflow...

Reason Nr. 1: Unclear Intent and Lack of Decisions

i.e. unclear goals on each level.

• The overall goal, the sub-goals of the sub-projects and the actual goals of the milestones are not clear to the whole team.
• The goals of the project, the teams and the individual developers are not aligned.
• Too many goals are pursued at the same time, each goal still has three options, there are no clear decisions for or against it.
• Unnecessary goals are achieved because the development project is technology-driven instead of customer-driven.

Solution: Write down Clear Operationalized Goals

• Operationalized goals means that it is clear what the product will do when it reaches the goal, or at least what the status of which documents and other artifacts in the project is.
  • It also means making clear what the product will not do, what the non-goals are.
  • We find it most efficient to work with intentions:
    • What does success look like?
    • What do we want to achieve here?
• Writing down means that the goals are formulated in a document accessible to everyone or, even better, on a team Wiki page.
  • Attention, trap: In many teams there is a very digital approach to goals: either nothing is written down, or then a huge "requirement management" formalism is created. Again, the middle way is the best, a few bullet points on a wiki page are better than nothing at the beginning, but also better than formally correct requirements, which are only finished at the end of the project...
• This does not mean that it is possible without requirements: requirements are indispensable as detailed goals.
  • It is also indispensable to understand that changes of requirements are part of every project.
  • As soon as requirements are written down, they can be discussed. If these discussions with all stakeholders from product management to developers are well lead, then the requirements will "automatically" reach the right level of detail.
• Decisions: just decide and put the results in writing.
  • We look at decisions as experiments, then they become easier: With the decision, we formulate a hypothesis. Then we test this hypothesis in practice, in an experiment. As soon as we see that we have taken the wrong hypothesis, we adjust it. If we have taken the right one, we don't have to adjust anything.
  • If deadlines are to be met, it is better to decide instead of waiting for additional information ("paralysis by analysis").
• Change management: What does not correspond to the objectives is a change, clearly identify it in the project and estimate the impact ("impact management"). This serves as a decision support for whether the effort in time and money is worth the change.

By the way, the clear formulation of goals and requirements invalidates the argument "Own employees and freelancers are easier to manage than an external (sub-)project because we don't have to specify anything": Own employees also have to know what they have to do!

Reason Nr. 2: No Realistic Estimation

• In many organizations the tools to make a meaningful estimate are missing, a number is written down from the gut.
• Often neither time nor employees are planned for a reliable estimate.
• Sometimes nobody wants to know the real effort, because the project is already sold at the price, the budget was planned without an estimate...
• Starting with a realistic estimate, no project will be approved.

Solution: Perform a Realistic Estimation

•  Realistic estimation means
  • to carry out an expert estimation, preferably with Planning Poker
  • two-point estimation (see e.g. estimation tools)
  • whenever possible attribute-based estimation (e.g. the implementation can be estimated well by most developers, the effort for design, testing, integration... are better multiplied as factors ("attributes"). If an organization has very stable processes, completely attribute-based estimates are also possible, e.g. development time per page of specification.
• If it is necessary for internal reasons, it makes sense to perform the "tuning" to a target value only after the realistic estimation, one can then always fall back on the first estimation.
• The effort really used in the project must be documented, so that the estimate can be checked after the project end and the factors for next estimates can be extracted from the project.
• A simple risk management with damages and probabilities of occurrence is performed.
  • The resulting risk belongs added to the estimate: If 10 risks of 500 hours of effort are estimated with 10% probability of occurrence (i.e., a risk total of 500 hours), then one of the risks can be expected to occur. This means that the project will have to spend 500 hours on it. Where will it get the 500 hours if they are not planned?
  • The risks, damages and probabilities must be tracked through the project, for example, on a monthly basis. And it's a pretty good indicator for an intervention if the overall risk doesn't decrease over the project...

Reason Nr. 3: No Clear Way of Working

• Each project is managed differently by each project manager, each team member uses the tools differently and understands the processes and terms differently.
  • Officially, everyone has ISO 9001, everyone does Scrum... In reality, everyone does what they think is good. And "agile" is too often the excuse for "chaotic".
  • It follows that no project can learn from another. There are good ways of working (also called processes) in individual projects. From which, because they were never written down, the other projects cannot profit.
  • Processes and their optimization is the task of a quality department. The engineers and especially the management do not feel responsible for it.
• Lack of responsibility/"ownership": It is not clear who is responsible for the  completion of each product of the project.

Solution: Enforce and Optimize Processes

• Whatever the basis, agile, V-model, stage-gate or waterfall, project management processes must be enforced.
  • Only then one can determine if they are viable at all and one can make them viable, adapt them, optimize them.
• Prepare the project: technically (architecture and design), organizationally and temporally (planning).
  • Otherwise it will be like when all (bricklayers, plumbers, carpenters, electricians ...) start to build the house together (without foundation, without plan, only with a vague idea)...
• Define in writing the persons responsible for everything that is to be done in the project.
• Define terms in writing, create a glossary.
  • It can be argued afterwards what a package test and what a module test are. If it is defined, then it is clear to everyone in the project right from the start.

Reason Nr. 4: No Reliable Information on Project Status

• Often in the management there is no idea about the degree of goal achievement during a project.
• There is a lot of controlling in the rear view mirror about accumulated efforts and costs in the project management system, however no information about the real project status and the problems (e.g. occurred and identified risks).

Solution: Define Intermediate Goals and Talk to the Team

•  Iterative delivery, plan and track intermediate goals.
  • The best practice here has been the agile idea of delivering a subset of the features as soon as possible every, say, four weeks.
• Update estimations and especially the risk list regularly, e.g. every four weeks.
• Try asking a team member about the status.
  • If the culture allows for an unfiltered answer....

Reason Nr. 5: No Effective Management

• Acceptance of the "fact" that development cannot be planned, ostrich behavior in case of overruns.
• "Salami slicing" is implicitly accepted, every project is budgeted too low and then re-financed.
• Belief in Parkinson's Law: we must limit time and budget as much as possible, otherwise the team has too little pressure.

Solution: Demand Predictability

• Require estimates and plans from the development team, demand improvement in meeting the planned goals.
  • If salami slicing is needed, use it just right to define intermediate goals: Each slice properly estimated and with clear targets.
• Do not accept overruns by factors.
  • But that often means accepting higher initial estimates. Which in turn has the advantage that financial decisions about product developments are made on a realistic basis.

And the effort for all this? In our experience, it's pretty much 10% of the project effort, much less than the 200 to 1000% without these measures....

And: the above also applies to many other technical projects (digitalization, IoT, IT...).

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!