Best project delivery approach selection - friend or foe - CITI
22974
post-template-default,single,single-post,postid-22974,single-format-standard,mega-menu-top-navigation,ajax_fade,page_not_loaded,,qode-title-hidden,qode-theme-ver-10.1.1,wpb-js-composer js-comp-ver-5.6,vc_responsive,mob-menu-slideout-over,yellow-block-header

Best project delivery approach selection – friend or foe

Best project delivery approach selection - friend or foe

What is your best project delivery approach selection? Firstly let’s be clear what we are talking about.  Is it your:

  • product delivery approach – with its focus on the management development activities

or

  • project delivery approach – with its focus on the management of the overall delivery?

 

It’s very easy to confuse the two particularly when the project’s benefit position is one of competitive advantage and one of the primary deliverables is a state of the art, leading edge digital or technology product.  A situation which inevitably will lead to a high degree of focus on the technical aspects of the project.

And who would argue against that?  The requirements are unlikely to be fully tied down and the potential route to develop the full technology behind the product vision is still uncertain?  In this instance the use of an iterative approach for the product development is a sensible way forward.  And, if that was the only deliverable, use a product delivery approach might be all you would need.

However, as competitive advantage is the desired benefit in my example, the ‘new technology’ surely cannot be the only deliverable required to achieve that result?

Without other essential deliverables, for example, sales and marketing materials, new processes and guidance for users – successful achievement of the benefit becomes increasingly uncertain.  And it is likely that these deliverables, maybe better suited to being developed in a more traditional way.

One example of this is the marketing materials.   If we assume that the brand and ‘look and feel’ of the marketing materials is known – only the content and product details are likely to be new and developed using a tried and tested standard process – almost certainly traditional rather than in an iterative way.

You may well be thinking ‘…what is my point?  What difference does this make?  

My starter for 10 response is where:

  • two differing approaches are involved it definitely becomes more complicated. The governance and decision making become a little more involved and there is an increased need for co-operation, communications and, critically, dependency management.

or

  • a less than desirable approach has been selected, unnecessary risk and complication are introduced. For example: if an iterative approach (Agile) is being used when the team and Sponsor (in my example Marketing) are used to predictive approaches (Waterfall) for their new materials   then there is likely to be increased uncertainty and an uneasy Sponsor.

 

But if you agree having the most suitable approach is important how do you decide which is best to select for developing your deliverables?

As you might have anticipated – it all depends.

For instance, how clear are the requirements, how experienced and available are your resources, what is the organisation’s risk appetite and corporate needs?   Are there any specific constraints?

Once you know these you can begin to decide which are the most appropriate product delivery (development) approach/es for your initiative.

In broad terms if:

  • all your requirements are well known or can be fully developed relatively easily and there is full agreement at outset – then predictive (Waterfall) is a good candidate
  • many, if not all, of your requirements are open to exploration and difficult to establish – then an iterative (Agile) should fit the bill.

 

A relatively simple and safe decision, on the assumption, of course, you have resources who are familiar with the best project delivery approach selection!

However, what if there is a mixed economy as in our scenario?

Simply choosing one approach over another without sufficient reflection and consideration may lead to increased cost, conflict and confused, or even discontented, stakeholders and sponsor.   And it’s possible that your core development teams may be similarly disenchanted if an unfamiliar development approach is ‘forced’ upon them.

In my view selecting two differing, but appropriate, product development approaches is the way forward for this type of initiative.

However, as always, nothing is that easy.   Making the decision to use differing product delivery (development) approaches in the same initiative inevitably has consequences of its own.  This is particularly so when considering the overall management and governance – the upwards management perspective if you like.

In the meantime if you would like to hear more or discuss best project delivery approach selection further or talk with us about how we can support you please contact me JNichols@citi.co.uk