Project Late Again?

Project Late Again?

Project Late Again?
Project Late Again?


I’m stealing an analogy from an old colleague – “Say it takes you 30 minutes to drive home and you have to be home by 6pm. If you haven’t left by 5:30, then you are already late, even though you might not acknowledge it”. That is the essence of projects being late – it’s not that they don’t end on time, it is that they don’t start on time. perhaps someone has correctly assessed it will take 9 months to deliver on an initiative, so a timeline is published; “We will start at the beginning of the year and deliver by the end of the 3rd quarter.” In January if the team were asked, “Has this initiative started?”, the answer could be “Yes – we are discussing the scope and issues – status is Green”. 

 There is no rush, right? There is 9 months to get it done. But typically, the “discussions” will last for months, and by the time a plan to deliver is completed, and actions are mapped to a timeline, it becomes apparent that the actions should have started 2 months previously.There are delivery models (Agile, SAFe, etc) that are great at delivering when intent/backlog has been defined. Getting that intent crystallized is what takes too long, and the reluctance to start any tasks before intent has been defined seems a wise approach. 

However (to steal another analogy), if you must make a sandwich but Product hasn’t told you what type of sandwich you need to make, it is arguably legitimate to say that nothing should be started until Product work out what type of sandwich the team should make. However, even without knowing the type of sandwich, you can still complete some actions. Stretching the analogy, you could get the bread, butter, knife, etc. Maybe you make some sandwich samples to help Product decide!  

The point is that waiting for Intent from Product will be a perpetual issue, so it needs to be handled. The first tactic is to time box the discussion on Intent and have a date by when, even if you are months away from going live, if you haven’t received Intent/requirements, the project status is Red. Not Yellow, not Green trending yellow, but Red. Don’t be shy. Raise this as a risk at the beginning of the project, and then trigger it! Executives actually love Red status as they can then feel useful discussing remediation.

I once was on a training course and we were set a 45 minute “warm-up” exercise to cross a six-foot gap with 4 wooden boards that were all shorter than the gap. Our team was still in discussion after 20 minutes as some were hesitant to start without a complete solution. We (of course) ran out of time. The team that was most successful explained in the post-exercise debrief that they had decided that even if individuals wanted to immediately try some approaches, the team agreed to discuss the problem for a minimum of 5 minutes.

 And that seems about right – discussions on discovery/intent/requirements should last for about 10% of the project timeline before work has to start. Not to say that intent discussions come to an end, but they would be continued in parallel with delivery. So, when developing the Project Roadmap, put that big star after 10% of the timeline is used, and that is when Sprint 1 starts, and plan all the other events accordingly.And if you have a 30-minute commute and must be home for dinner by 6pm, but you haven’t left by 5:35, then call home and admit you are already late – maybe dinner can still be saved!

The Author :  Stuart Hamilton 

 Stuart Hamilton

About :  
To structure the delivery of complex, large-scale transformational projects while managing and coaching multidisciplinary and matrixed teams. Day 1 assistance to develop strategy, roadmap, and execution plan, then execute and manage the implementation.

Post a Comment

Previous Post Next Post