HOW TO SHORTEN A PROJECT #1 – THE QUICKEST WIN OF ALL - PM 360 Consulting
19481
post-template-default,single,single-post,postid-19481,single-format-standard,wp-custom-logo,theme-bridge,woocommerce-no-js,ajax_fade,page_not_loaded,,qode-content-sidebar-responsive,columns-4,qode-theme-ver-11.0,qode-theme-bridge,wpb-js-composer js-comp-ver-5.1.1,vc_responsive

HOW TO SHORTEN A PROJECT #1 – THE QUICKEST WIN OF ALL

HOW TO SHORTEN A PROJECT #1 – THE QUICKEST WIN OF ALL

 

 

 

If you want to shorten a project there is one place where – more than any other – this can be achieved.

This is right at the beginning, as soon as the idea for the project is born.

You don’t have to take my word for this.

In their book, Developing Products in Half the Time , the authors Smith and Reinertsen refer to the beginning of the project as ‘the fuzzy front end’. They say this: ‘Time is an irreplaceable resource. When a month of potential development time is squandered, it can never be recovered … each month of delay has a quantifiable cost of delay. Our goal as developers is to find opportunities to buy cycle time for less than this cost. These opportunities, large and small, appear throughout the development process. There is, however, one place that we could call the ‘bargain basement’ of cycle time reduction opportunities. It is the place that we consistently find the least expensive opportunities to achieve large improvements in time to market. We call this stage of development the Fuzzy Front End of the development program. It is the fuzzy zone between when the opportunity is known and when we mount a serious effort on the development project.

 

If the ‘fuzzy front end’ is where ‘opportunities to achieve large improvements in time to market’ are greatest, then learning to scope and plan a project in a day is the best way of maxing out those opportunities.

If you don’t scope and plan the project in a day, what’s the alternative? It goes something like this:

1. Somebody identifies some kind of need or requirement or problem that needs to be solved.
2. Based on this somebody does some ferreting around and then writes a proposal / business case / specification.
3. This is reviewed by the stakeholders (those people affected by the project) and the reviews are fed back to the author of the document.
4. There are updates to the document, plus perhaps flurries of e-mail exchanges, phone calls, requests for information and meetings to resolve various issues.
5. Items 3 and 4 get looped around a number of times until finally …
6. There is agreement on what we are going to do.
7. Then somebody is charged with building a plan.
8. That somebody does some ferreting around and then writes a plan.
9. That plan is reviewed by some or all of the stakeholders and the reviews are fed back to the author.
10. There are updates to the plan, perhaps more e-mails, phone calls, requests for information and meetings – particularly if there is a gap between what the stakeholders want and what the project team say is possible.
11. Items 9 and 10 get looped around a number of times until finally …
12. There is agreement on the plan.

 

This process can take weeks … months … years, in some cases.

As an alternative to all of this carry on, you can scope and plan the project in a day.

 

Article written by Fergsus O Connell 14th August 2017

www.fastprojects.org