Back to the Coalface of Project Management

Project management remains a popular subject, and this series of articles, here, here and here were amongst the most read early in the life of this blog. The originals were written with a strong emphasis on our experience of establishing supply chains in developing markets, so to extend their appeal they have been combined and updated with content relevant to a wider range of situations.  This post also provides a background for our next articles.

Coal

Why Projects Fail

This article looks through the lens of our experience ‘at the coalface’ to give you insight into how to develop a project that works.  Unlike strategy, which is highly reliant on innovation and uniqueness to create a successful ‘roadmap’ for the future, project management has a well-established format for completing on-time, on-budget and to the right quality.  Despite this well-known framework, project failure is far from uncommon. So why do so many projects fail?

There are many factors, but context our experience tells us that these 6 are the major stumbling blocks:

  • Scope uncertainty.  At the start of the project it is essential to clearly outline the scope. This is not a design, although that will become a part of the scope, but rather clear descriptions of the expected outcomes. In supply chains this is usually expressed in terms of capabilities: Typically these could include capacity, cost per unit produced, inventory turns, return on capital etc. Most projects are about creating something, and defining clearly what the expected outcome looks like is essential. Without a clear scope, monsters will infest your project.
  • Lack of resources.  New projects and initiatives require considerable amounts of time above and beyond business as usual.  Budget or headcount restrictions often dictate that organisations look to existing resources.  The predictable outcome is that something isn’t done well, or done on time.  That something is usually the project work.
  • Divided accountability and responsibility.  This often goes hand in hand with the previous point.  If the project team members end up with more than one manager as a result of finding themselves on the project, then it can divide their accountability and responsibility to the project.
  • Hostility.  Multiple and diverse reasons exist for hostility towards a project.  Envy, fear, uncertainty and doubt to name a few. Uncontrolled these can kill projects.  Dealing with this is a key role of the project sponsors and leaders.
  • Disconnects with reality.  Projects exist in the real world where constraints and restrictions are the rule, and not the exception.  Refusing to recognize them doesn’t make them go away.
  • Absence of sponsorship.  Projects need sponsors.  With sponsorship, the failure points above can be acted upon.  Without it they will not be.  Internal or external consultants can be critical in identifying the key pressure points for project sponsors to enable timely intervention.

These six points have a common origin in project governance, and particularly leadership and sponsorship.  Being aware of these risks and planning to avoid them is critical to project success.  In the next part of this post we will cover how to define project scope.

What You Need to Know About Scope.

Without a clear scope, you will be constantly challenged by changes to the end-state vision, or the project manager’s deadliest enemy, scope-creep.  In the preparatory stages of a project you will find two documents essential to define the scope:  These are the project proposal and approval document, and the project kick-off document.  Although these are deceptively simple in their format, the information and decisions that they record define the project’s objectives and key descriptions of what success will look like.

The proposal and approval document presents in one to two pages the key information necessary to move a project from a proposal to an approved part of the project portfolio or programme.  The project objectives are summarised in a paragraph or a few bullet points.  The benefits and expected costs are outlined, and the key resources and timings.  Dependencies to other projects are determined, and known risks briefly described.  A summary of the strategic fit aligns the project with overall business objectives.  Finally the form provides a section to record the approval to proceed from the business leaders responsible for authorising the expenditure and allocation of resources.

The project kick-off document contains more details about how you organise the project to achieve the project goals.  It is often necessary to put together much of the content of the kick-off document to be able to prepare the proposal for approval.  It is used as the agenda and materials for the kick-off meeting with the team selected to implement the project.  Here are the main sections of a kick-off document:

  • Background, why the project is being initiated.
  • Strategic fit with overall business objectives
  • Goals and deliverables.
  • Scope, what is included, and what is not.
  • Top-level work breakdown structure and main workstreams.
  • Project organisation structure.
  • Review process (review meetings schedule and reports required).
  • Financials.
  • Level 1/2 Gantt chart with key decision point milestones.
  • Risks and dependencies.
  • Key next steps.

Each kick-off document is unique, but for an organisation that is constantly evolving, it is useful to develop standardised formats to ensure nothing is missed at the kick-off stage.  Most of this information applies to all projects.  Perhaps the most critical input at this point of a project is to create a work breakdown structure that accurately reflects the time and effort that will be required to complete it. For large projects, with multiple functional areas and processes it will likely be necessary to organise into workstreams, each with their own organisation and resources to execute the necessary tasks.

Once the project has been kicked-off it is crucial that the project sponsors take full responsibility for adherence to the agreed scope, and are the only part of the project organisation that can agree to any changes to the goals and deliverables.

Sponsors and Governance

So by now your project scope is clear, the work is planned, and the resources are in place.  You have made a good start to the journey, but how will you navigate the long road ahead?  In many ways the answer is to plan for failure, or more specifically how to avoid it, and governance is the key activity.  What is governance, who does it, and who benefits from it?  Simply put, governance is how the project owner gets the information needed in order to keep the project moving towards a successful outcome.  Large projects typically impact across many operational areas, and as such a separate organisation structure is required to ensure work is completed as planned, and information flows to the key decision makers and project owner, commonly referred to now as the sponsor.  Often overlooked is how to deal with the many issues that can lead to project failure. Which is where the project sponsor earns his or her money.

Lack of resources can seriously impact a project even when there is a clear project organisation chart with defined responsibilities.  Projects compete with resources for ‘business as usual’ operations, and with other projects.  The business environment never stands still and changing operational priorities often pull the project team members away from completing crucial tasks.  When the project organisation is new, communications within it are often less effective than those in the regular business operations.  Schedule slippages due to lack of resources can quickly build up between the formal project reviews.  A key project management role at this stage is to continuously monitor that all the project resources are fully mobilised and that their scheduled tasks are being completed as planned.  If resources are constrained, the sponsor’s role is to step in and make the judgment call between operational requirements and project objectives, and agree this with the organisation’s leadership team.

Accountability and responsibility can be divided as a result of projects, especially when project team members retain operational responsibilities alongside project roles.  Emotionally, the project team members are likely to prioritise operational requirements above project requirements, especially if the project could impact on their future within the organisation.  The project manager needs to be able to rely on the resources they have to be fully accountable, and responsible for their tasks. If this is not the case, then the sponsor needs to ensure corrective actions are made to re-focus the team members or replace them.

Hostility to a project is common but often underestimated.  Some stakeholders and even project team members can be openly or passively obstructing the project. Identifying and dealing with this is crucial, and is a key responsibility of the project sponsor.  The project manager rarely has the authority to deal with these issues, especially if they cross formal operational hierarchies.  The project sponsor must have the executive authority to be able to raise hostility issues with the organisational leadership and take the necessary actions.  These can be ‘make or break’ moments: Projects that no longer have the full support of the board should probably be halted, or be ‘ring-fenced’ to fully separate them from the rest of the operations.  If opposition is external to the project organisation then this needs to be identified as a key risk and managed through communication, incentives, reward structures or disciplinary actions.  If hostility is likely to be widespread from the outset, a formal change management programme may be required to manage this risk.

Disconnects with reality are frequent: We have noticed this especially when a project is in a new market or business area that the leadership is unfamiliar with.  Expectations that the new markets can be managed in the same manner as existing ones can be misguided, and usually result in the symptoms of a failing project.  Timescales may be unrealistic, cost estimates wrong, and the new market may have barriers to entry that exclude existing business models.  This leads to dysfunctional outcomes, lateness and budget overruns.  Sponsors need to make clear the realities of the business environment and manage expectations appropriately.

Absence of sponsorship is usually fatal to a project, and arguably should be.  If there is no senior leader that is willing to back a project, it should be humanely killed before it succumbs to predators.  If your project has not got a clear business benefit that the executive team is counting on you to deliver, and an equally clear commitment from them to getting it completed, then why are you doing it?  Quality of sponsorship is the key indicator for project success. Sponsors need to be committed to the business case for the project, and have the authority and influence to resolve these well-known reasons for ‘Why Projects Fail’.

If you want to learn more about the Cosmapec approach to supply chain development, visit us at http://www.cosmapecsupplychainmanagement.com or contact us

About :  Rob Ward has extensive global experience working in supply chain organisations.  He co-founded Cosmapec to help companies and executive teams establish, develop and optimise their supply chains.

 

Lessons Learned: Plan A or Die is Not a Contingency

In the early life of this blog I shared thoughts on ‘Why Projects Fail’.  It was written with hindsight of working on multiple projects a year, over many years.  I am proud of the many successful projects I have been involved with, but I have also worked on ones that have failed.  Project failures can be career threatening and are, at best, depressing when they happen, but they are still useful.  The Queensland Health payroll system failure report from the Commission of Inquiry should be read by anyone who undertakes large projects. It is lengthy and complex, as befits an inquest on failure of a colossal scale.

I have learned much from reading it, and there are many lessons that I take away from it.  The over-riding impression is that ‘group-think’ eventually dictated the actions of those involved to such an extent that they ignored even the most explicit warnings of the impending disaster.  One of the investigators for the inquiry termed it ‘Plan A or Die’.  But before that, they condemned it to failure by committing all of the well-documented major mistakes that lead to project failure.  Each one alone can be fatal to a project.  All of them in one project is stunning, and that one of the world’s biggest and most widely-admired companies failed to deliver a solution which is central to their core business proposition is a salutary lesson to us all.

The main conclusions include:

  • No single point of responsibility – in other words, no sponsor.
  • Scope was never established, and no one individual or group ever accepted responsibility and accountability for defining it.
  • The main contractor provided neither the quantity nor quality of resources to complete the work.
  • Accountability for the project was divided over multiple governance committees, and none of them discharged their duties responsibly.
  • The main operators of the payroll system were openly hostile to the solution that was being delivered.
  • And as noted earlier, group-think disconnected the team from the reality that their chosen course of action would inevitably end in disaster.

A major part of the failure was in the choice of contractors; despite clear warning signs that the chosen contractor was ‘low-balling’ the price to make their bid irresistible, and that the leader of the selection process had serious conflicts of interest that would favour this supplier, they went ahead and awarded them the contract.   (Note to self: Add in conflicts register to anyone involved in the procurement process for future projects.)

At every point thereafter when they could have, and should have called the project failed and started again with a newer provider, they refused to administer the coup de grace. Even when issued the clearest and unequivocal warnings that the solution would not and could not work they pressed on, despite alternatives being available to them.

This one of many conclusions from the report speaks volumes to why the project output when delivered, two years late and more than four times higher than the original contract price, failed to work.

(The supplier) relied upon there having been completeness in the communication to it of the State’s business requirements.  The State on the other hand seems to have thought that (the supplier) having agreed to deliver a payroll solution would be obliged to deliver one that paid staff and did so accurately, even if all (the State’s) requirements had not been communicated and found their way into the various scoping documents.  This was folly on the part of those within the State who took that view.

If you take nothing else from this tale, sordid as it is, remember that quote.  Projects deliver benefits from the solution to the end customer.  In this project, the requirement to accurately pay their staff was wilfully ignored by those who held the responsibility to do so.

What lessons have you learned from working on projects?  Please do share your experience in the comments section so all readers can benefit from your knowledge.

If you want to learn more about the Cosmapec approach to supply chain development, visit us at http://www.cosmapecsupplychainmanagement.com or contact us

About :  Rob Ward has extensive global experience working in supply chain organisations.  He co-founded Cosmapec to help companies and executive teams establish, develop and optimise their supply chains.

Project Recovery: First, Make Sure It’s Dead

The two hunters joke pivots on a double-entendre.  Two hunters are out in the woods when one of them stops breathing and collapses.  The second one calls the emergency services, and the operator advises, “Firstly, make sure he’s dead”.  A short silence, punctuated by two gunshots, is followed by the punch-line, “Yes, now what”.  This instantly sprang to mind when reading this article, at Ricardo Guido Lavalle’s blog .  The point of the article is that you can’t do project recovery on one that hasn’t been declared dead.  Still live projects, infested by monsters, will continue to wreak destruction until they stagger to their untimely and expensive end.  Bernard Morris provided me with a classic example here of Queensland’s payroll project disaster. Which brings me back to this article’s title: A bereavement is necessary before project recovery can begin.

Projects fail for multiple reasons, but sometimes, not quite failing is worse.  Whilst there is hope, belief in the ‘rightness’ of the project will still be strong, whatever the evidence to the contrary.  Refusal to kill pet projects or strategies, no matter how ruinous they have become, can be deadly.  It recently cost Ed Miliband his job, and has dealt a serious blow to the future prospects of the UK Labour party.  Despite consistent polls showing that their leader was unelectable, and substantial evidence that in general elections the British vote for the Prime Minister they want rather than the party they represent, their belief in their strategy was unwavering.  Until the results came in.  The strategy failed, it was clear why it would fail well before it did, but hope and belief kept it alive.

The Queensland payroll IT system, budget A$6.19 million, ultimate cost A$1.25 billion is staggering.  I am going to be fascinated to read how this evolved as I work through the report of the official inquiry.  A glimpse into the root cause had already emerged at the time the inquiry started, as one witness observed that the Queensland state had neither an appropriate organisation, or the quality of management to execute a project of this scale.  Given that quality of governance is a good yardstick of project success, this is probably going to feature large on the outcomes of the inquiry.  I am going to be most interested in how the financial controls were set up, and how the state approved a A$1.25 billion overspend before it put the project out of its misery.

Projects in themselves are not sacrosanct, but those who believe in them often believe they are, and will see success even when it is obvious to all that it is a disaster.  The tell-tales are when missed deadlines come with requests for more cash, and threats of disaster if it isn’t forthcoming.  The next time this happens in a project near you, it is time to call the Lord-High Executioner, despatch it to wherever projects go to when they are dead, and start again.  Sure, there will be outpourings of grief, but delaying the inevitable is only going to compound the misery.

Is project recovery important to you?  Please do share your experience in the comments section so all readers can benefit from your knowledge.

If you want to learn more about the Cosmapec approach to supply chain development, visit us at http://www.cosmapecsupplychainmanagement.com or contact us

About :  Rob Ward has extensive global experience working in supply chain organisations.  He co-founded Cosmapec to help companies and executive teams establish, develop and optimise their supply chains.

Scope-Creep Thrives on Free Lunches

Few challenges in projects have survived the assault of the Project Manager’s growing arsenal of control and execution tools.  Business success increasingly depends on projects that drive change and innovation, and there is constant focus on cost, schedule and quality when implementing them.  Despite this, scope-creep seems to have escaped and even thrived. So how can you spot scope-creep and how do you prevent or control it?

The tell-tale signs from scope-creep attacks are everywhere:  Project horror stories abound on the internet and in real-life. Most have a common theme; a lack of clarity on who owns what needs to be done, and a Kafka-esque metamorphosis of a well-intentioned idea into a grotesque and ugly creature with no clear use or purpose.  Scope-creep is the often invisible hand that drives these disasters.  When we talk about scope-creep, we don’t mean planned change, for that is necessary and inevitable: After all, the world changes and projects need to adapt just like any other business activity.  But un-budgeted and unplanned changes without a clear business benefit are the distinguishing characteristics of the scope-creep monster, and when you let it into a project, it hollows it out with its insatiable appetite for more.

To keep the beast at bay, set-up your defences at the beginning of a project’s life.  Controlling changes in scope starts with the initial project goals. What should be the output, defined in terms of business objectives?  If this isn’t identifiable, pay US$200 and head back to ‘Go’.  Make sure you know what success looks like before you start. (Projects may have elements of R&D in them, but it should be more D than R).  The next big danger and flashing light is a lack of formal governance, and the biggest omission of all is absence of an authorisation process for change-order management.  Scope-creep makes its home here and it can grow at an alarming pace.  Once it has been established that project features can be changed at will, then the requests come thick and fast, until they overwhelm the project team.

As noted earlier some changes in projects happen because they must respond to events. Some projects will last for years and the final specification of the end-solution is not easily described at the start.  In these circumstances change-orders are the norm rather than the exception. The key that locks the door before scope-creep get its toe inside is to organise the change order process around the engineer’s maxim: You can only have two from the requirements of cost, quality and speed.  If you want high-speed and high quality it will cost you more.  Low-cost and high speed translate into poor quality, and low-cost and high quality will take longer.  Failing to heed these constraints leads to changes in deliverables that are neither budgeted nor scheduled.

Sponsor and project owner pressure to do more with fewer resources is inevitable.  It is after all the key to productivity. However being able to clearly define the schedule and budget impact of changes is an essential part of the project manager’s toolkit.  Treat the change requests like small stand-alone projects and make what needs to be done clearly defined, schedule the tasks, get costs approved and add them to the budget.  Scope-creep lives off free lunches, in your project, there ain’t no such thing.

Is scope-creep thriving in your project?  Please do share your experience in the comments section so all readers can benefit from your knowledge.

If you want to learn more about the Cosmapec approach to supply chain development, visit us at http://www.cosmapecsupplychainmanagement.com or contact us

About :  Rob Ward has extensive global experience working in supply chain organisations.  He co-founded Cosmapec to help companies and executive teams establish, develop and optimise their supply chains.

Learnings from the Coalface of Project Management – Part 2. What You Need to Know About Scope

If project failure is so common, how can you prevent it?  Let’s consider the first of the major risks identified in last week’s discussion, scope uncertainty.  Without a clear scope, you will be constantly challenged by changes to the end-state vision, or the project manager’s deadliest enemy, scope-creep.  In the preparatory stages of a project you will find 2 major documents essential to define the scope:  These are the project proposal and approval document, and the project kick-off document.  Although these are deceptively simple in their format, the information and decisions that they record define the projects objectives and key descriptions of what success will look like.

The proposal and approval document presents in 1 to 2 pages the key information necessary to move a project from a proposal to an approved part of the project portfolio or programme.  The project objectives are summarised in a paragraph or a few bullet points.  The benefits and expected costs are outlined, and the key resources and timings.  Dependencies to other projects are determined, and known risks briefly described.  A summary of the strategic fit aligns the project with overall business objectives.  Finally the form provides a section to record the approval to proceed from the business leaders responsible for authorising the expenditure and allocation of resources.

The project kick-off document contains more details about how you organise the project to achieve the project goals.  It is often necessary to put together much of the content of the kick-off document to be able to prepare the proposal for approval.  It is used as the agenda and materials for the kick-off meeting with the team selected to implement the project.  Here are the main sections of a kick-off document:

  • Background, why the project is being initiated.
  • Strategic fit with overall business objectives
  • Goals and deliverables.
  • Scope, what is included, and what is not.
  • Top-level work breakdown structure and main workstreams.
  • Project organisation structure.
  • Review process (review meetings schedule and reports required).
  • Financials.
  • Level 1/2 Gantt chart with key decision point milestones.
  • Risks and dependencies.
  • Key next steps.

Each kick-off document is unique, but for an organization that is constantly evolving, it is useful to develop standardized formats to ensure nothing is missed at the kick-off stage.  Most of this information applies to all projects.  Perhaps the most critical input at this point of a project is to create a work breakdown structure that accurately reflects the time and effort that will be required to complete it.

If you are expanding supply chains internationally and into developing markets particular attention needs to be given to the legal and financial structure to be adopted by any new companies you create to operate in each country.  The regulatory environment should also be thoroughly investigated to understand the impact on costs and timings for selling and distributing products.  Each of these may need dedicated workstreams to design the optimum structures and organisation to meet the project objectives.  You will often benefit from good local knowledge and experience when these critical decisions have to be made.  Protecting intellectual property should be a key consideration when you decide on the business structure to be used, particularly if joint ventures or local manufacturing are required.

Once the project has been kicked-off it is crucial that the project sponsors take full responsibility for adherence to the agreed scope, and are the only part of the project organisation that can agree to any changes to the goals and deliverables.

If you want to learn more about the Cosmapec approach to project management and managing change visit us at http://www.cosmapecsupplychainmanagement.com