Article Overview
This article explains the 8 phases of a project. 1st phase is with the project kickoff, 2nd phase is exploration, the design would be the 3rd phase of a project. Find out which are the rest of the 5 phases of a project.
Table of contents
- Project Phase 1: The Project Kickoff
- Project Phase 2: Exploration
- Project Phase 3: Design
- Project Phase 4: Development
- Project Phase 5: Testing
- Project Phase 6: Training
- Project Phase 7: Deployment
- Project Phase 8: Post-Deployment
- Summary
Whether your customer is around the corner or around the world you need an official Kickoff session, strategy session, planning session…whatever you want to call it. With a planned and productive Kickoff session, the project gets off on the right foot and you, as the project manager, will have done your best to start everyone off with the same expectations. Of course, there are no guarantees on that, but at least you are likely to close some major expectation gaps and possibly identify some risks that you hadn’t counted on. The PM methodology that I’ve been using while leading customer implementations is sort of a hybrid, but it’s been well received by the customers. I’ll discuss the phases of the methodology in subsequent posts, but for now I’ll explore in greater detail how I believe a typical Kickoff session should go.
Preparation
As the PM, prepare an agenda and presentation materials – probably a Powerpoint presentation – and share all of it with the customer well in advance of the Kickoff session so you can incorporate their feedback and address any additional information needs they may have. You’ll potentially be meeting with a fairly diverse crowd at the customer site and they may have some requests for discussion points at the Kickoff that you haven’t thought of yet. At one recent customer Kickoff meeting, I had a team of 4 with me and the customer had over 30 representatives for the 2-day session. That’s overkill and can definitely slow things down, but it happens so be prepared.
Face-to-face Kickoffs are great and are usually recommended, but if logistics and/or costs are an issue, then a webex should serve the purpose. Just be as communicative up front with the customer as possible – especially if you’re running the Kickoff remotely – as this is your first chance as the PM to form a relationship with the stakeholders on the customer’s side.
For the actually Kickoff session, here are the major agenda items I usually like to address:
SOW Discussion
The task here is fairly obvious. It’s a high-level overview of the Statement of Work that was hammered out – usually by Sales – with the customer. Here’s where I will once again make my stand that the PM org should be involved upfront so that the SOW would likely fall better in line with the customer’s business needs heading into the delivery portion of the engagement. At least the ‘gaps’ would be more apparent upfront.
During the SOW discussion, any issues, gaps, concerns, etc. should be noted so that they can be addressed either during the next phase of the project or noted as potential risks.
Review Project Stages/Methodology
This is where the customer gets what is likely their 2nd insight into your PM methodology (Sales probably provided the 1st insight). However, this is where you can tell the customer how you, as the PM, will run the project, how each phase will happen and what the expectations and deliverables are for each phase as they pertain to this specific project.
Define the Project Team
Next we introduce the project team. Of course, for some of the roles, there will be no name yet. Depending on the size of the project and the size of your organization, many of the resources will not have been officially assigned yet, but the roles and responsibilities for each role will be known at this point and can be shared in detail with the customer. At a minimum, the PM and the BA (Business Analyst) have been assigned and both are or should be part of this Kickoff session.
See more: 10 Characteristics of successful project teams
Discuss Risk, Issue and Change Management
At this point, discussions of risks, issues and change management is likely to be brief. Risks and issues will flesh themselves out more during the exploration and design phases of the project. However, how risks and issues will be handled as well as how change and change orders will be handled and executed on the project should be discussed in detail and will be of great interest to the paying customer.
High-Level Project Plan Review
Finally, a quick review of the project plan – at least at a high level – needs to happen. If this is the first time the customer is seeing a project plan, then it probably should not be too quick. Both sides need to discuss each phase, the milestones, deliverables, and overall timeframe as well as all tasks that will be taking place over the next 1-2 months.
I refer to Phase 2 as the Exploration phase. Ideally, the customer has performed some process analysis and requirements analysis on their own prior to the kickoff of this phase of the project. The customer should aspire to head into the Exploration phase with a decent – and hopefully documented – concept of their current business processes as well as what their future state (ie, post-implementation) processes need to be. The primary goal of the Exploration phase is to nail down the overall business requirements for the project so that both teams leave the Exploration phase with a common understanding of the requirements that the system or software will be developed against.
The primary deliverable of the Exploration phase is the Business Requirements Document (BRD) and it should require a formal customer signoff. Without that signoff, the Project Manager could be chasing scope issues for the duration of the engagement. In my opinion, and usually, general practice for external customer projects, every one-time deliverable on every project should receive a formal customer signoff. The BRD deliverable from this phase is the document that lays the groundwork for the creation of the Functional Design Document (FDD) or Functional Requirements Document (FRD) – depending on what you want to call it – which is your primary deliverable for the next phase of the project – the Design phase.
It’s worth noting here that on projects that are smaller or with very tight timeframes, the Exploration phase and the Design phase can be compacted into one combined phase. I usually refer to this combined phase as the Design phase. I don’t recommend it if it can be avoided as separating the phases allows a deeper dive into the business requirements and provides you with a better chance to go into Design with a common understanding of the requirements you will be developing the system to meet. However, it’s not always possible so this is a good chance to gain some time back for the critical Development and Testing phases if the timeframe is tight.
The Exploration phase should kickoff with a meeting of both project teams. At this point, the delivery team really still only needs to be comprised of the Project Manager and the Business Analyst – at least that’s all that absolutely needs to be in front of the customer during this phase. The customer team should be represented by the project sponsor and the SMEs (Subject Matter Experts) from the relevant business areas or units affected by the project so that the business processes and requirements can be discussed in detail and finalized.
Weekly status reports and formal weekly project status meetings – usually held remotely – begin with the Exploration phase and continue throughout the rest of the project. Issues and risks are revisited and re-assessed throughout the Exploration 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.
Exploration Phase Deliverables:
- Business Requirements Document (BRD)
- Revised Project Schedule
- Revised Risk/Issues List
- Project Status Reports
- Weekly Project Status Meetings
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:
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 on-boarded. 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 requirements
- Reporting requirements
- Data migration requirements
- Data integration requirements
- Security (if applicable)
- 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
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 the development and continually aware of the progress
Managing a team of developers, a Business Analyst who may be getting tugged to the edge of the 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 the project schedule is critical. It must be part of the weekly status report, the weekly status meetings and a touchpoint 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 ’80s 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 Project Viewer's 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 /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 the 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
Now we have a developed system that hopefully matches the customer’s requirements to the letter and we’re ready for system testing before moving on to the customer-side User Acceptance Testing.
Preparation for testing test consists of three activities:
- The Testing Approach - sets the scope of system testing, the overall strategy to be adopted, the activities to be completed, the general resources required and the methods and processes to be used to test the release. It also details the activities, dependencies, and effort required to conduct the System Test.
- Test or QA Plan (deliverable) - details the activities, dependencies, and effort required to conduct the System Test and UAT.
- Test Conditions/Cases documents - the tests to be applied, the data to be processed, the automated testing coverage and the expected results for the System Test and UAT.li>
Read: 5 ways to improve project testing
System Testing
Led by the Application Developer or Developers and other architects, data integrators, etc. who may have worked on the project, the developed system must undergo rigorous testing in preparation for UAT by the customer. All modules – separately and together – must be tested against the BRD, FDD, and test scripts that have been developed. All data integrations must also be tested to ensure that the system interacts with other systems (ERP, SAP, CRM, etc.) as expected.
Ideally, testing is done on a separate platform utilizing test management tools or server from development as this tested and finalized testing environment would then pass form System Testing into User Acceptance Testing.
User Acceptance Testing
In the case of a software/IT project, the customer comes up with their own test scripts and scenarios to rigorously test the system prior to deployment. It is a serious conflict of interest to have the delivery team create test scripts for the customer to utilize during UAT.
The customer should assemble a team of SMEs for the UAT activity and ensure they are free of other obstacles during this critical phase of the project. Depending on the size of the project, UAT is likely to be a 1-2 week activity.
Signoff
Once the customer is satisfied with the delivered and tested system and all necessary test scripts have been run through satisfactorily by the customer, the PM must obtain an official signoff of the system. This is critical to ensure success and scope maintenance going forward. Following official UAT signoff, we’re ready for our next phase – Training.
To recap…
Testing Phase Deliverables:
- Developed system (no signoff required)
- QA Plan (deliverable – signoff optional)
- User Acceptance Testing signoff
- Revised Project Schedule (revised weekly as needed)
- Revised Risk/Issues List
- Weekly Project Status Reports
- Weekly Project Status Meetings
The key things that need to happen during the Training phase are:
- Development and delivery of a Training Plan
- Development and delivery of training materials
- Set up of a training environment or server with a production-ready copy of the system
- Training-specific data loaded to the database
- Delivery of training, or train-the-trainers training
Training Plan & Materials
Development of a Training Plan and training materials has likely started during the User Acceptance Testing activities. At that point, the system is developed and system-tested by the delivery team and is hopefully 99% production-ready. Therefore, the delivery team – most likely the Business Analyst – can begin the task of putting together the Training Plan and training materials based on what needs the customer has for training.
Training Environment & Data Load
For an IT project, there likely also needs to be a separate training environment/server set up for use in training the customer. This, too, should begin happening during UAT. As the Training Plan is being developed, the Project Manager needs to also ensure that useful, meaningful training data is ready and loaded into the database for the training session or sessions. This task will likely be performed by a data migration specialist who has already been working on the project preparing any necessary customer data for loads into the production environment and therefore is familiar with the data needs and loading requirements and timeframes.
Training Delivery
Depending on the size of the user-base, there needs to be decisions about who is being trained and the materials must be geared specifically for that audience. If the user-base is small, then it may be practical to train nearly everyone on the developed system. If the user-base is very large, I highly recommend a train-the-trainer approach where the delivery team – again, likely this will be primarily the BA or a professional trainer – trains key customer SMEs or trainers on the system and then those individuals conduct training sessions for others within their own organization. The materials for those future training sessions will need to be developed – at least in part – by the delivery team, but the training will be conducted by the customer.
Up Next
Depending on how the training approach is planned out, Deployment – our next phase – may happen either at the end of the train-the-trainer sessions or once all training is done. Either way, UAT has provided everyone with official, production-ready signoff for the system and once training has been completed to an agreeable level, then Deployment of the production-ready system can commence.
To recap…
Training Phase Deliverables:
- Training plan (deliverable - signoff optional)
- Training materials (deliverable – signoff optional)
- Training environment
- Training data in training database
- Revised Project Schedule (revised weekly as needed)
- Revised Risk/Issues List
- Weekly Project Status Reports
- Weekly Project Status Meetings
We are now ready to discuss the actual deployment phase of the project. A successful UAT has been completed and signed off, the training process has been completed and we’re ready to move the production-ready solution to a production environment and signoff on go-live.
Production environment
Sometimes during training on an IT project, the production environment has been readied – either hosted on the delivery team’s side or at the actual client site. Either way, considerable setup (and already agreed-upon ordering of equipment, etc.) has happened and environment testing and performance tuning have likely taken place.
Production data load
Depending on the dynamic nature of the live data for the project, the timing and process for the production data load can be very critical. The key, of course, is to perform the data cutover as close to go-live as possible while maintaining business continuity and ensuring the on-going integrity of the data.
Data cleansing, data preparation and data loading has been underestimated and undervalued on more than one IT implementation and can sometimes be a make-it-or-break-it variable in the project schedule and project budget. However, a good Project Manager, Software Developer, Data Integrator, and Software Architect will have already reviewed the data closely early in the engagement and undergone at least partial test loads to the development, testing and training environments. So, as the delivery team readies for go-live, the actual data load to production should be well thought out and fairly straightforward.
Customer review/go-live signoff
Once the production environment is set up and tuned, the production data is loaded and the production-ready system is given the green light by the delivery team, it is time to get official go-live signoff from the customer sponsor or designated representative. This is critical…don’t let it slip through the cracks. Depending on how your project is set up and how billing is handled, this could mean the difference between your company getting that next pay installment or accounting showing up in your office wondering why the last invoice is 90 days past due. Get official signoff. If the customer is happy and things are going well, they’ll sign off. If things are sketchy, stay with it, ensure the customer that the same team members will be engaged in Phase 8 – Post-Deployment for ‘x’ number of days and that you’ll be right there to support them performing any break/fix work. Either way, get them to officially sign off on paper for the go-live.
Up next
We’ve deployed the system and now we’re ready for production support. I believe in a Post-Deployment phase where the original team is available for, say, 30 days after go-live to support the customer, handle concerns and perform break/fix work before passing everything off to technical support. It’s a show of good faith and keeps the customers coming back for more work.
To recap…
Deployment Phase Deliverables:
- Production environment
- Live data load to the production environment
- Deployed production-ready system (signoff required)
- Revised Project Schedule (revised weekly as needed)
- Revised Risk/Issues List
- Weekly Project Status Reports
- Weekly Project Status Meetings
This final Project Phase post concludes my overview of the hybrid PM methodology that I use whenever possible on PM engagements. The final phase – Phase 8 Post-Deployment – occurs post-implementation and suggests a more hands-on level of post-implementation support from the delivery team. First, to recap, the first seven phases we’ve covered so far are:
There are a few ways to go about your post-implementation activities on an IT project. One way, of course, is to just hand your customer off to the tech support group and treat everything as a potential ticket. If you’re set up well to track trouble tickets and have a very competent IT support staff, then this method should provide you with a great tracking mechanism and should provide your customers with solid support. However, before doing the hand-off to tech support, I suggest you perform another step first.
In a Professional Services organization, the PM, the BA, the developers, the architects, and the data specialists likely all have other active projects as well as new engagements they’re starting to roll on to. However, I am a firm believer in doing whatever possible to keep the existing delivery team at least partially together to provide hands-on, call-me-on-the-batphone type support to your newly implemented customer for at least a 30-day window – 60 would be even better. Why? Because it’s good business. Because it may mean the difference between future engagements with this customer and them moving on to another vendor next time around. Because you’ve held the bicycle and ran alongside them for probably 6-12 months and you shouldn’t just push them out into the street now that they’re finally getting the hang of it.
They’re going to fall…something always breaks. And for at least a post-implementation 30-day window, the people who know it best - who just finished implementing the solution - should be the ones doing the break/fix work quickly on it. Trust me, your customers will agree. If it isn’t part of your company’s sales discussion, then I wouldn’t be surprised if the customer brings it up during Project Kickoff. It’s important to them and during the project, they’re constantly looking toward that day when they have to take their first steps alone…and it scares them. Make it easy…and stick with them.
At this point, it’s also a good idea to re-connect with the customer on one or more meetings to come up with a Lessons Learned knowledge database. This will help in three areas:
- Provide the delivery team with good feedback and useful info for future engagements
- Document project-specific issues that may be relevant to tech support after hand-off
- Increase customer satisfaction and provide the customer with useful project information as they move into the post-implementation support mode
Once the agreed-upon Post-Deployment support window is complete, train the customer on your ticket submission system or ensure they have direct phone access to tech support. You’ll also need to bring tech support up to speed on the customer-side project team or production contacts and provide them with any relevant information that came out of the project that will help them going forward to provide the best support possible to the customer. If you’ve produced a Communications Plan for this project, this is a great time to update it with post-implementation contact information on both sides of the project and re-distribute.
Just to be clear, the process phases that I've covered describe different phases of an IT project, BUT this is only an example. These are the PM methodology/process that I normally use for IT projects. If you have any questions, feel free to post them in the comments section at the end.