Five systemic problems with many projects - recognise many of these?
When projects are reviewed (whether they are going well or not) a systematic approach is always taken. Yet the reality is that when one thing goes awry there is often a ripple (systemic) effect of other things going wrong as a direct or indirect consequence. Projects are not perfectly logical or systematic. Yet systematic audits may tell us we have to fix 118 things out of 500 - but how does that help? What we need to know is which ones to fix first (and how many other things will be indirectly resolved by doing that). We can only resolve one thing at a time anyway! We need an intelligent "escape route" that prioritises the things we need to correct or change.

In our experience the following factors (rarely alone) are the most frequently observed problems that projects face when off-track. I wonder how many of these resonate with your own experience?
  1. Inconsistent governance
  2. Unclear objectives & the business case
  3. Poorly defined scope, requirements & over ambitious projects
  4. Inadequate stakeholder management
  5. Realistic plan
Stacks Image 612
1- Inconsistent governance
Good governance is the single-most important aspect of projects. PRINCE2 is the most often touted method - but is it applied well? Not in my experience. Far too often project boards are too large, have inappropriate (non) participants adding little or no value, want only to hear good news, and waste valuable time. Governance: look it up! Whatever happened to "providing advice, guidance and support" or project board meetings that take well-informed, consistent and pro-active decisions quickly? Isn't it time to actually apply good practice rather than point to our exam certificates?
Stacks Image 659
2- Unclear objectives & the business case
Business cases typically offer a single cost, schedule and scoped deliverable at the start: achieving this becomes increasingly unrealistic as time passes. As a minimum, the worst and most-likely case scenarios should be considered to ensure that the business case will be robust and secure, whatever happens in the wider business environment. On that basis only, the objectives for a project flow directly.

A business case with
flexibility by design enables cost, schedule and scope/quality to be traded as circumstances change over time, but still within the limits of the original business case. and the originally stated and agreed objectives. If (as occasionally happens) the business case is invalidated during the project, then the project is reliant upon the quality of the project plan's flexibility to determine what the recovery plan or alternative approach needs to be. That is the point at which we need to know what is really important to deliver to the business - how much that costs, how long it takes and what the minimum acceptable deliverable needs to be. However, more often than not we see projects simply continue apace…and guess what happens next?

So is it defeatist to consider what happens should the business case not be realised; or is it good planning? How many times have we seen money "wasted" attempting to ensure the IT system processes 100% of the transactions including all possible exceptions; rather than settle for processing 95% of all transactions and using a much smaller amount of money to address the exceptions (manually or otherwise)?
Stacks Image 666
3- Poorly defined scope, requirements & over ambitious projects
Scope is defined by a statement (words) maybe a diagram and definitely a WBS/PBS. The temptation to skip the WBS exercise and produce out a Gantt chart that declares "real" dates simply sets expectations to unreachable levels before we even start.

It's easy to buy into an expectation set by a salesman; almost impossible to delver against it! Projects that are simply too ambitious and too long - the supplier's business case is not yours! And project managers cannot be expected to inherit a supplier's sales pitch project plan and deliver it.

The bigger the project the greater the number of requirements; the longer it takes to capture them; the longer the design; the longer the build. Projects can only assign a precise cost and schedule if all the requirements to be delivered are defined to a low level - a situation that is rarely seen. If requirements are still at a high-level when the project begins, it is critical that the project objectives, business case and plan all have built-in flexibility because the scope (ergo solution) is not yet defined.

And throughout the duration of the project, changes emerge until there is change upon change and (no matter how good your team are), they cannot push wet string uphill. Trying to establish too big a project (even if it's given a grand name like "integrated business transformation") is simply asking for problems. Even small, relatively non-complex and deliverable projects face a real challenge in dealing with scope changes. Scope creep may be seen as an opportunity by some, but for the project manager, it should not be viewed with rose-tinted spectacles. Once the shared vision of a team is clouded (for whatever reason), the chances of successful delivery are significantly reduced. A Standish Report
[1] records a 55% success rate for projects of less than 6 months duration whilst another reports 50%; and after 9 months' duration another [2] observed successful projects.

Scope is the most traded variable by projects to "bring a project-in successfully" yet is often the least well-defined, described or communicated at the outset.
Stacks Image 678
4- Inadequate Stakeholder Management
Projects increase in complexity exponentially with the number of key stakeholders; so does the amount of work required to manage those stakeholders. And in reality many projects begin knowing that opposition will emerge. Although it may seem counter-intuitive, it is far better to work through out the issues up-front than let them fester. Project managers and sponsors do not want to be seen to be starting arguments - but handled correctly they needn't be confrontational but rather they can reconcile stakeholders to solving a set of problems upon which they agree.
Importantly, if there is a major problem, it may be that the project needs to take a different form: better to plan an acceptable project, than be blocked and fail to deliver an unacceptable one?
Stacks Image 700
5 - Realistic Plan
Planning seems to be a lost art/science. An inappropriate focus on application planning software has much to do with this, and conversely the lack of focus on planning skills. So why do we see so little evidence of best practice planning; much of which is well-documented? Plans often begin as a "happy day" version of events where everything is delivered right first-time and on-time…hmmm. Some of the features we have noticed are:
  • Dependencies (particularly external ones) are assumed and not managed (as risks) and the plan fails
  • Inappropriate granularity (too vague or too detailed) and planning horizons
  • Poor (often merely single point) estimation
  • Absences not planned/modelled/tracked
  • Lack of islands of stability or business cases that reflect them (see [2] above)
  • Risks and opportunities are (not?) kept independently and separate from the plan!
Risk management is the difference between a "happy day plan" and a realistic one. Risk (ergo change) management is essential to any plan.
Errors in planning are compounded by project teams keen to be seen to be "delivering" rather than planning. However activity is not the same as progress. The desire to start working still supersedes the need to define what the end goal looks like and work towards that objective!