For example, consider a project team that's assigned to build a new e-commerce application. The team follows proper project management principles, and performs their work exceptionally. The site is completed, the business owner has accepted, and the project team executes their closeout tasks. Then, five days later, the business owner calls the project manager and asks him to run audit reports off the system. The project manager responds that it's the business owner's responsibility. This leads to the discovery that no one is trained to be the project's operational owner.
Was the project manager naïve to believe the project was over? Sort of. Because even if your review of the project planning documents reveal that all the requirements were met and user acceptance was completed, only an external consulting team would have a chance of getting away with this argument.
In a real-world scenario, the project team would be in very real danger of becoming the product's operational owner. Why? Because they're the only ones who have the knowledge to run the system.
Reasons why this situation may occur
Although extreme, this situation is very common--and not because a project manager fails to execute the project correctly, but rather due to a failure in planning for the product's post-project operationalisation.
Here are several other reasons why you may find yourself in this situation:
- 'We'll cross that bridge when we come to it': These conversations are common in early planning sessions because much of the project foundation information is yet to be discovered. As a development manager, I've routinely said this to my project leads. My expectation, however, is that the project manager will make a note to revisit this later in the project cycle.
- Poor communication of responsibilities or bad assumptions: Both of these factors are directly within the project manager's scope of responsibility; you should resolve them before project closeout.
- Inexperience or lack of knowledge: Many project managers aren't skilled IT systems or architecture professionals. In this circumstance, the project manager may simply not have enough knowledge or experience to ask the right questions. This is where the project team technical leader needs to have some accountability.
Keep in mind that the business world views IT as a single entity. Unless you work in a rare and truly projectised organisation, your business areas will not typically distinguish between project teams and operational support. For them, you are IT. Walking away after a project is completed is a mark of failure if you aren't supporting the client's needs.
Post project - all your good work feels like it is falling apart - again!
Many project managers are reluctant to let go of the project and see their good work (Process improvement, ownership, relationships that were forged) lapse back into apathy and the same old same old. To make matters worse, operational people often recognise that when you were managing this work, it was done faster, smoother and was better communicated... so when they need something operationally again once things have returned to normal, they ask for your help. Saying no is hard, because you feel like you have let them down (and your good work go)
But, its not your responsibility any more, the project manager should move on… let the operational teams deal with their operational environment.