Monday, 1 August 2016

BCS PROMS-G Spring School 2015: Project startup. Is there an art to getting it right?

Once you have the results from the spike you are ready to start the project. That will develop the excellent feature or product from your roadmap. How the actual project then starts can have a massive effect on the results.

On that topic "Project startup. Is there an art to getting it right?" was subject in the BCS PROMS-G Spring School in 2015. One session I enjoyed was  Project Start-up - Acknowledging the Outside World. Here two members of the National Audit Office (NAO) shared observations from reviews of large projects.  Often problems in government projects are as a result of issues at the project start. They estimate that around 75% projects late/over budget. So, £300bn of tax payers money at risk (seems to be cycle where much better in election years before going up ;)

The NAO approach has been to pay more attention to major projects. Looking at value for money and delivering, rather than just cutting costs. Alison and Grace then talked about the report "initiating successful projects". This discussed the five factors that affect project delivery. (There is also an interesting paper on over optimism )

Performance management was one of the biggest issues found. Often that no performance management system. Second biggest was that people don't know what they want, which leads to scope creep. Third is uncertainty due to lack of stakeholder consultation. Finally, bit odd coming from an auditor was culture. Were they bidding low to win work? then not wanting to upset the apple cart etc

One NAO case study discussed in detail was the FiReControl project. On this project, there was no business case before starting work. During the planning, there was no critical path analysis. This lead to building's construction work finishing before IT systems contracts let. The relationships were also poor between team, stakeholders and contractors. So the infrastructure and IT aspects of the project were not coordinated!

In a nutshell planning for success involves:
  • Benefit articulation - Why is this project a good idea? what's the vision?
  • Relationships - How are the communications between stakeholders?
  • Organisational capability- Do you have the skills needed to deliver the project?
Grace and Alison then did an exercise using the Delivery Environment Complexity Analytic (DECA). This is a framework for risk analysis highlighting the points above. This covers 12 factors in the following three areas:
  1. Priority (vision)
  2. Feasibility (Realism)
  3. Delivery Capability (team)
This was a great exercise. We looked at a bridge project to see what we thought the potential pitfalls were. Even knowing little about the details we were able to explore areas for investigation. These were things like the experimental nature of the bridge materials. Or the expectation of usage and behaviours of commuters. The DECA link above includes a blank template and usage guide.

We then had a panel discussion and I've noted the key takeaways
  • Communication is key.
  • Decisions need to be taken by the appropriate people. So don't make proxy decisions in project team!
  • Need commitment from exec to enforce governance (and not allow workarounds or ignoring plans).
  • Lots of different "languages" used according to context. The BA had hard job in removing context to keep meanings for requirements.
  • How to deal with "dishonesty" in reports. This could be a form of delusion due to POV and context, e.g. Policy vs operational in civil service and once policy decided hard work all done. (This is a risk I've seen, implementation is often underestimated).
  • Interesting one from NAO. Fixed price contracts bad for startup. Any supplier who plays the game can make *any* scope change or requirements an oversight cost. Time & materials with cost/person/hours a month specified much easier to budget.
  • When changing people's behaviour via an IT project own it and agree that first. Don't leave the IT supplier to take the rap. You need to factor in and manage the business change.
  • Finally, there was a great perspective on new PM coming into to restart failed project. They are not "better" but coming in with fresh perspective and a focus on future. This can have a massive impact even if similar skills and experience.

R for Product Management

Photo by  Štefan Štefančík  on  Unsplash Since my previous blog post I have made some progress on being able to replace most of what I...