You have all the deliverables completed & signed off, but the new service just seems to struggle and flail like a fish that just hopped out of the bowl and onto your desk. And while you may have moved on to the next project, the business service owners fighting with the last implementation are now muttering under their breath.
How can this be avoided?
One sure fire way is to be thinking of the "transition to operations" from the outset of the project planning & chartering. And think about how this service will be supported and operated daily by the people who will be responsible for it, and the people who will be using it. Likely, you've already got those considerations on your check-list, and that's great.
But are you making sure that the operational & support documentation delivered through the project reflects this?
Here are, for your consideration and feedback, three simple ideas to ensure that the documentation to support the hand-over of the completed project are both useful, and used!
Build in time for the experts to document their work.
One of the most common concerns a PM will hear from the IT subject matter experts - the technicians, analysts, or engineers on their project team - is that they only have enough time to do the work, not write a story about what they've done.
It is your responsibility as the PM that your project plan and task lists (work breakdown structure. etc) include ample time and clear expectations that any system configurations, support procedures, or operational maintenance tasks are documented clearly.
Communicate this expectation clearly, early, and often. But it won't be enough to tell the team what to do; you need to empower them to do it.
Provide the experts with simple tools to document their work.
It's often not going to be enough to tell people what to do. A true leader will lead them; show them what is expected and support them in getting it done.
Have some simple templates available at the outset of the project to share with the technical experts supporting the project delivery. Don't accept "it is self-documenting" as an answer. Ever. It really isn't.
You should review all the support and operational documentation output of the project. You don't necessarily need to understand every nuance, but you DO need to be able to read it and get the gist.
Technical experts are rarely writers by trade or skill. It's just not what they do. They will take short-cuts in their documentation, and rightly so, as they understand it - they built it!
But what happens in four or five years when the service needs an overhaul and that particular person isn't with the organization any longer?
What happens when the project rolls out and a more junior resource is tasked with operating or supporting the technology aspects of the new service?
Consider these scenarios when reviewing the documentation with the technical authors.
And those tips help get the documentation needed by the technical folks completed - but what about the support model for the service?
Have the end-users of the service contribute to the support model.The documentation to ensure that the service has a clear model of support, escalation paths, and service expectations should always have input from a small, careful selection of those who will be active end-users of the service once it goes live.
Be selective in who you involve, and bring them "nearly completed" drafts of the support model to review and contribute to in order to respect their time and keep potential re-writing to a minimum.
Following these simple tips should help others see what a great IT PM you really are.
If you have other tips and tricks for IT Project Management, or feedback on these ideas, please share them with me in the blog comments or via my Twitter account - @itManageCast
Thanks for reading, and have an awesome day!
Post a Comment