How to generate better luck on large projects.

Today’s topic will include a look at typical project cycles and how to dramatically improve the 'luck' experienced on a project.

This posting focusses mainly on the Start-up and Final Delivery phases of a typical project and answers the question: What can we do during the start-up phase to promote success during the final delivery?

We will approach the answer by first looking at the 'What' and 'Why' before moving on to the 'How' and 'Who'.

So lets get started...

How can we generate better luck on our projects?

Step 1. Make sure you have the end in mind before you start.

  • Identify the high-level project deliverables along with the main business drivers. (Business Case)

  • These are powerful navigation tools essential for steering the right course.

  • Conduct a study of who your Stakeholders are and what benefits they'll want from your project.

  • Meet with your customers and ask them to help you to help them. Sounds cheesy, but it's a great way to build rapport and calibrate your approach. This will also demonstrate to them that your project is focussed on delivering benefits and not just another sterile solution.

  • Develop an 'Elevator Pitch' for the project and have this adopted by your management team.

  • Create a detailed Product Breakdown Structure taking into account the stakeholder input.

This takes care of the ‘WHAT’ and ‘WHY’ for your project. Now let’s look at the ‘HOW’ and the ‘WHO’...

Step 2. Conduct a full inventory check on the resources you and your team have at their disposal:

  • People, skills, expertise, budget, time, infrastructure, sponsorship support etc.

  • Consider the timelines for when these resources may actually be needed.

  • Assess any gaps between the project demand profile and what you can supply in terms of resources.

  • Work out how to fill the gaps. For example request more funding, skills etc. This is where you show your initiative and resourcefulness.

Step 3. Measure Measure Measure !!!

  • There's an old saying: "What doesn't get measured doesn't get done."

  • How will you know when you get there?

  • Look at the Product Breakdown Structure and work out ways in which to measure the successful delivery.

  • Carefully decide on the quality criteria for each one.
  • Try applying the GQM method to get started.

  • Make sure they are SMART criteria.

There is a strong cause and effect relationship between the decisions made at the start of a project and the ease of success of the output.

In short, effort invested in these techniques at the beginning will amplify the luck experienced at the end.

All the best,

P.s. Feel free to comment on this blog with your own experiences.


  1. I couldn't agree with you more, Colt. The linch-pin for measuring project progress and ultimate success as defined by stakeholders and sponsor has to be the business case.

    The business case defines the value-add a project's success will have on a business's strategy. I'd also suggest that communication / engagement with stakeholders is critical to this. Effective comms and expectation management can make or break a project delivering on its promised value-add as any other factor.



  2. I agree with this completely, but will add one thing along the inventory check... Assess what you know, but more importantly what you don't know!! Identify the gaps and make sure you pin them down before you start. Risk risk risk, be aware of it or it will bite you on the ass.

    Lotsa Love


  3. 1. Write your test scripts following your PDWs and integrate testing throughout the development phase

    2. From a strategic perspective, projects are like fish flowing in a river...certain fishes have more potential, higher ROI, etc. A set of rules need to be applied to the strategic net in order to pick the fishes with maximum potential.

    3. Project orientated managers have a habit of "Where's my actions", "Lets get on with it". The balance between discussions and actions has to be fine-tuned.

  4. Make change requests as formalized as possible, this will in a way, intimidate the lazy stakeholder and s/he will refrain from submitting all those (in many times useless) changes. This is the art of controlling change requests.