I'm starting this blog with the hope that one day I will reach the finish line and look back and find that I have managed the perfect project. It is an elusive catch, this perfect project, but every day I get a little closer to finding it.
So I'll start with a little context. I am an IT Project Manager working directly for the government. I'm not a contractor, though I was years ago. This is an important distinction because PMs who work as contractors only see about two-thirds of the overall work. There is a lot of work that goes on in what Steve McConnell calls the 'fuzzy front-end'. While I'm not a big fan of all of McConnell's work, I tend to agree with him on this point. Contractor's become involved after two significant events have occurred, 1. Money has been budgeted to the project, and 2. A Contract has been awarded.
I know that contractors will claim that they have to develop a proposal and generate their bid. I understand that there is cost and work in there, but these are time-boxed elements. That means they aren't too fuzzy. The development of the business need, quanitification of work to be performed, and the number of people who must sign off each step of the process is almost always unknown work that takes forever. Suffice to say, I will touch on the fuzzy front end frequently.
The Next aspect centers around the responsibilities of the Contract Officer Representative (COR). This work represents the work to write the Statement of Work (SOW) or Statement of Objectives (SOO), develop an Independent Government Cost Estimate (IGCE), develop a Quality Assurance Surveilance Plan (QASP), market research, contract types, Chair the Technical Evaluation Panel (TEP) and write the Technical Evaluation Report (TER). Often times writing a Best Value Analysis is part of this work as well.
After project kick-off we dive in to Project Monitoring and Control. It is here that you better have a good grasp of all the PMI PMBOK functional areas. Weakness in any single area could sink a project. I will probably pay too much attention to Management Plans because I think too many people don't pay any attention to them. If your project doesn't have managment plans for things like scope and risk, stop now.
I will also have to delve into some of the more geeky aspects of IT development. Specifically in the Software Development Lifecycle (SDLC) because the deliverables you receive should not just be to check a box. They should help to propel your project forward. If your deliverables aren't doing that, then you need to think about what kind of visibility you need into the project to know that it is going well or to take corrective action if it isn't. I will definitely talk about iterative development and how to identify the pretenders from the professionals.
I will very likely focus on an area that is often overlooked in Project Management, adoption. Too frequently training, and user manuals are cut out of a project. I know that it isn't done on purpose. But there is work in those activities and just because you received software that passes some test doesn't mean the project is over. Customers are paying for a product that helps the business. They aren't paying for something that sits on a shelf somewhere. If you build the tool exactly to spec and nobody uses it are you successful? I would say no. To pass your PMP exam, say "Yes". But I think the work isn't done until adoption has been achieved.
Finally, work still isn't done until we have had a chance to hold a lessons learned meeting and identify areas for improvement for next time. I like to trick it out and hold a full-fledged Post-Implementation Review (PIR). It is only after that meeting that you can sit back and say that it is done.
These are the areas I hope to cover to share my experience with the world and help the profession of Project Management. I can't guarantee that I'll post every day, but I'll try to get something every week.
-Tipy
No comments:
Post a Comment