Published on Wednesday, January 14, 2009
To recap, so far I’ve covered the first three phases of the PM methodology/process that I normally use for IT projects – at least in some modified version:
To this point, we’ve delivered to the customer the following:
Personally, I believe in an Iterative development process with on-going demos on dev progress to the customer to:
Managing a team of developers, a Business Analyst who may be getting tugged to the edge of scope by the customer-side project team, and a sundry of other vendor-side support personnel such as architects, data specialists and integration specialists can drive a Project Manager crazy. Keeping a good check on project schedule is critical. It must be part of the weekly status report, the weekly status meetings and a touch point on most ad-hoc communication that happens daily on the project.
I personally started managing very large 5-year long government programs/projects worth tens of millions of dollars back in the late 80’s and early 90’s using ABT’s Project Workbench in the old DOS era. The move to MS Project improved things considerably and has been a staple to the present. I’m also intrigued by Seavus’ ProjectOffice.net (www.projectoffice.net) offering and am in the process of familiarizing myself with it. I will work to cover it in an upcoming post as I see it as an incredible value as project management tool, scheduling tool and collaboration tool for not only small companies but also large companies. And the price beats MS Project 2007/MS Project Server as a collaboration tool by thousands and thousands of dollars. That alone makes it worth a look.
Anyway, that’s for another article, but I had to mention it all because management of the schedule is so critical – especially when we get into the Development phase and face potential change orders, development reviews and feedback from the customer. Scope management at it’s finest!
A Technical Design Document (TDD) is a documented outcome from the Development phase. It may or may not be an actual deliverable to the customer. If it is, it is really only for their documentation purpose – it should NOT require a formal signoff as it is really a documented representation of the ‘as built’ solution. This may make it easier for future system changes by the original vendor, the customer, or a third-party vendor or it may be a document that helps the customer during future upgrades. Either way, it’s a nice to have and up to you or whoever you report to as to whether you hand it to the customer.
Weekly status reports and formal weekly project status meetings continue throughout the Development phase. If you take my advice and follow an Iterative development process, then you’ll be scheduling – and delivering – periodic development reviews. These will be basically periodic demos of progress on the development of the software functionality. At some point, weekly reviews are nice and may be necessary, but we’ll refer to them as ‘periodic’ reviews since the entire length of the Development phase will govern how many of these there are and how often the will occur. Issues and risks are revisited and re-assessed throughout the Development phase and continue to be a review item during the weekly status meetings.
Development Phase Deliverables:
If you are interested in conveying your message to your target market, please contact us at firstname.lastname@example.org!
Share you project management knowledge and expertise with the hundreds of thousands readers of PMTips.net. Apply here!