Phase 4 – Development

• Phase 1 – Project Kickoff
• Phase 2 – Exploration
• Phase 3 – Design

To this point, we’ve delivered to the customer the following:

• Kickoff meeting
• Revised schedule (on-going)
• Business Requirements Document (signed off)
• Functional Design Document (signed off)
• Weekly status meetings (on-going)
• Weekly status reports (on-going)
• Revised risks/issues list (on-going)

Personally, I believe in an iterative development process with on-going demos on dev progress to the customer to:

• Ensure the developed solution meets client needs and expectations
• Identify scope issues as they arise
• Provide an opportunity for change order work/additional revenue in a timely manner
• Make the customer feel involved in development and continually aware of progress

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 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.

To recap…

Development Phase Deliverables:

• Technical Design Document (TDD) – this is optional and does not require signoff
• Periodic development reviews/demos – scheduled as required by the project
• Revised Project Schedule (revised weekly as needed)
• Revised Risk/Issues List
• Weekly Project Status Reports
• Weekly Project Status Meetings