imageimage
A Quick Guide to Project Management Methodology

Phase 3 – Design

To clarify, the process that I am going through to describe the various phases of an IT project is really just an example. These are the basic phases I’ve generally been using for projects that I manage. The phases are definitely subject to change based on several influences:

  • Size of the project
  • Budget for the project
  • Customer preferences
  • Timeframe
  • Availability of project personnel
  • PM methodology of the company you are working for (if applicable)

Once the exploration phase is complete – marked by the official customer signoff of the Business Requirements Document (BRD) – then the design phase is ready to begin.

If your project has the luxury of breaking exploration and design into two separate phases then by all means do it. Few projects suffer from extra planning and requirements analysis up front. However, as I mentioned in my post on the exploration phase, these two phases can be combined if the timeframe or budget for the project is compacted – and this combining of the phases may allow the delivery team more available time for the Development and Testing phases.

The goal of the design phase is successful completion and signoff of its one main deliverable – the Functional Design Document (FDD). The design phase still mainly consists of the Project Manager and the Business Analyst on the delivery team side. One or more developers may be involved – depending on the complexity of the project. However, it is more likely that they will be assigned to the team closer to the conclusion of the design phase. The customer side will vary, but is likely made up of the project sponsor, possibly a customer-side PM and the SMEs from exploration or a subset of the SMEs from some of the key areas of the company that will be affected by the implementation.

Key things that the PM and BA will need to dive into in the design phase with the customer in preparation for producing a solid FDD are:

  • Functional design requirements
  • Reporting requirements
  • Data migration requirements
  • Data integration requirements
  • Security (if applicable)

Keep in mind that this list is obviously geared toward IT projects. Also, it can vary greatly depending on the type of project, the demands of the customer and the size of the project.

Weekly status reports and formal weekly project status meetings continue throughout the design phase. As with the exploration phase before it, issues and risks are revisited and re-assessed throughout the design phase and documented as part of the weekly status report or as an addendum to the weekly status report in the form of a risk register or issues list. For our purposes going forward with these phase discussions, we’ll assume that it is a separate risk/issues list aside from the status report.

By the closure of the design phase the team members who will be supporting the Development effort in the next phase should be identified and onboarded. The FDD will serve as their basis for getting up to speed on the requirements for the project and what they will working from during their development effort.

The FDD should flow through a peer review on the delivery team side as this is truly the working document going forward for the project. The BA is the primary author of the FDD, but it should be reviewed by the PM, 2-3 other BAs and at least given a cursory review by the developer or developers assigned for the next phase of the project. Once it has the delivery team stamp of approval, the FDD is delivered to the customer for review and ideally a swift signoff, though it is more likely to go through some iterations of revision prior to a final agreement and signature.

To recap…

Design Phase Deliverables:

  • Functional Design Document (BRD)
  • Revised Project Schedule (revised weekly as needed)
  • Revised Risk/Issues List
  • Weekly Project Status Reports
  • Weekly Project Status Meetings
  • Assignment of Development team members and other support personnel

➤ Back to the Overview