I’ve noticed that successfully implemented large projects create more work. From my experience, this work surfaces in the following ways:
Resolving an issue resulting from the new system reported across the business.
The resolution for the issue could be short and simple and what needs to be done is blatantly obvious, such as adding a pre-existing field to a pre-existing report or re-training.
There is, however, the possibility that the solution will require its own full blown project – including requirements collection, level of effort evaluation, project planning, etc.
Having a sound issue intake, evaluation and prioritization process within your operations will help identify those monsters before they become expensive resource-sucks.
A component of the project neglected at go-live and needing attention
Often, this happens either because the project was over-scoped to start with (trying to do way too much at once with too few resources) or because there were problems with the main component of the project.
A common example – the staff-facing component of an enterprise system successfully launches at go-live, but the public-facing component is bare-bones, ugly, and barely usable. The organization needs to staff-facing component to work and drive the public-facing component, so the project appropriately focused its limited resources on getting that running.
Getting the public-facing component looking and running correctly should be a new project. Especially since doing that well often engages a new group of people with different skills and often results in role changes between the business units.
In a recent project – the IT department led the staff-facing component of the project. Much of their effort and focus was spent on moving and validating legacy data, configuring the back end of the tool, and making sure the integrations worked.
Once the business was ready to address the public-facing component, the Digital Marketing team took over leadership of that portion of the project and used the visual design, web development and UX expertise they possessed to make the public component work just as well as the staff-facing component. Ultimately, the public-facing component became its own project with its own budget and resourcing – as it probably should have been in the first place.
Implementation of new functionality that was not part of the original scope
As the business gets more comfortable with the tool it has implemented and learn more about available features, they may choose to create a new project to leverage that feature. An example of this is the implementation of a Project Management tool and later launching a project to leverage the resource management functionality within that tool.
——————
These initiatives surface on top of the need to move the results of the original project into operations.
And it is not just one of these that occur. Often all three of these scenarios, plus troubleshooting, plus the move to operations all happen at the same time – soon after the project and with a very tired pool of project resources.
The mistake I made in my last big project was not planning for these scenarios and engaging in appropriate stakeholder management at the beginning. As a result of this oversight on my part, everyone was overwhelmed with demands and the lack of focus meant next to nothing got done beyond firefighting for a month afterwards – much to the disappointment of the business.
I’ll admit – I’m not entirely sure it is realistic to expect much more than firefighting the 2-4 weeks after go-live.
Still, I think that going in with a solid post-project plan that includes a discussion of how to prioritize surfacing initiatives after the project stabilizes will go a long way in reducing some of the angst the business experiences when it can’t fix and do all the things right now.
One (of many) lessons learned.
Leave a Reply