Tributaries

Imagine a high-stakes, politically sensitive IT implementation.

During the project, things go wrong. Really wrong. As in – having more than half of your risk register come true wrong.

The project team fights and claws its way towards go-live – somehow managing to get everything working literally 15 minutes before having to walk into the Steering Committee for a go / no go decision.

They made it.

Barely. And not unscarred.

Time for celebration.  Even if many members of the team are too tired to get excited.  The more pessimistic ones (including the project manager) are just waiting for the next thing to break.

The business, however, is VERY excited.

They see that they can now do things they couldn’t do before.

So, of course, they want to do it…like….now.

They want the project team to cross the next raging river.  Then the next. Then the next.

And those rivers are close together.  Smaller, perhaps…but they still require crossing.

—————

I liken it to armies marching through Virginia during the American Civil War.

If you notice the eastern side of this map (from Addison’s History Blog) – each dot is next to a river.

There are a LOT of rivers.

And this map does not reflect the small tributaries that also needed to be crossed.

There were no interstates or fancy bridges crossing those rivers.

Often, bridges needed to be built.

Or they needed to be crossed carefully- a few soldiers and pieces of equipment at a time.

 

The experience of the project team immediately post-project is like that.

We crossed the big river – but we still have many smaller ones to cross.

————

I made a mistake planning my last big project.

I didn’t account for those river crossings after the project. Not just getting everything functional for movement to operations.

And, because this was a very politically sensitive project, I did post-project planning well before I realized that we were going to struggle so badly during go-live.

My post-project plan was too aggressive. WAY too aggressive.

The saving grace was having a project champion who recognized this before I did.

————————————–

My lessons learned:

• Plan for the post-project river crossings. What are the deliverables that are expected soon after the project? What are their deadlines? How hard are those deadlines?
• Create 2 project plans – best case scenario (the project team can do all the things) and worst case scenario (the project barely launches, the project team is exhausted, the system is still unstable, and help desk tickets reporting technical issues are rolling in).
• Perform the same level of risk analysis for post-project and transition to operations that you did for the project itself.
• Perform the same level of scope definition for post-project and transition to operations that you did for the project itself.
• Plan for at least 1 week of recovery / vacation time after 2-4 weeks for the entire project team.  That vacation will be forced with illness or general malaise around that time anyway (at least from my experience).
• Work with the Project Champion to manage the expectations of the business towards the worst case scenario – in my experience it is better to under-promise and over-deliver than to over-promise and under-deliver.
• Work with the Resource Managers to keep the project team for the month after go-live to stabilize the system and any new processes. Resource Managers want to rush team members back into all their old tasks + new initiatives as soon as go-live hits.  That is a recipe for burning out your project team members. It is also a recipe for not getting any business value out of your new system – because your human resources are too stretched.
• Work with the project team to manage their own expectations of themselves. I was fortunate to be working with a group of people who put a lot of heart and soul in their work. They WANTED to do all the things. Even for superheros – there are limits to time and energy and cognitive bandwidth.