The Implementation Phase in Project Management

The Implementation Phase in Project Management
By Jessica Popp

In its simplest form, Implementation is generally considered by team members as when the project starts. In a phase-controlled project, project team members are only minimally involved prior to the implementation phase. At this point, the scope should be approved and the project is starting in earnest. Implementation is very often the longest phase in the project lifecycle.

From a software perspective the traditionally agreed upon sub-phases include requirements, design, develop/build, and test. These can be extrapolated in many different ways and approached using different methodologies such as Agile, XP or countless others. But, at the core of the project you are managing these four things:

• Understanding in a documented way what the end customer needs/wants (Requirements)
• Extrapolating the understanding of the requirements into a technical specification to prove that the wants and needs of the customer can be addressed (Design)
• Making the requirements a reality (Development/Build)
• Test the results for accuracy/completion (Quality Assurance or Testing)

I’ve stated the above bullets in a generic way to demonstrate that these sub-phases or something similar are applicable across many disciplines. Titles may vary by industry but the end-goals are the same.

The requirements gathering phase is, in my opinion, one of the most critical phases of the project. Poor or lacking requirements are a key contributor to scope creep and missed project deadlines. As I mentioned in the planning section, it’s important here as well to get physical sign-off on customer requirements. The value is two-fold. First it helps your end customer(s) understand the importance of defining what they need while making it clear that there is a stopping point in the project for issuing new requirements. Additionally, it creates a point at which requirements are considered complete and any future changes should go through a formal change control process which protects the project from scope creep.

In software, the design phase is where engineers take the requirements and propose a technical solution that satisfies the customer requirements. This affords an opportunity to determine gaps or issues on paper before physical implementation takes place. This process lends well to other disciplines as well. An architect, for example, would never proceed to building without showing a plan (drawing) of the proposed house to his clients. This allows the architect to implement on paper all the requirements or wishes of the customer. It’s obviously much easier to catch a misinterpretation of requirements in the paper drawing rather than after the house is built.

In the build phase, the team takes the design and builds the final product. This might be software, the building of a house, the implementation of newly defined processes or countless other project outputs. At the end of the build phase all of the customer requirements should have been accounted for in the end product.

In the testing phase, you are validating that all the customer requirements were met and the end product functions as expected. In a house, this might include building inspectors certifying that the house meets code and the end customer doing a walkthrough of the completed home to check that their expectations were met. In software, this involves testing the software against the customer requirements to make sure everything functions as it should. In many projects testing can be iterative with the build phase with testing happening incrementally throughout the build process. This is often beneficial in finding issues earlier and finding issues earlier are generally easier to fix.

Now all of this sounds straight forward and even easy in a perfect world. In this perfect world, we wouldn’t need project managers because everything would go as planned. In the real world, it’s the project manager’s job to help the team get through the implementation phase by carefully managing timelines, risks, issues, resource challenges, scope creep and a myriad of other challenges. This is where Monitor & Control come in.

Jessica Popp is a practicing project manager in software engineering. She has more than 13 years experience in software development, project management and people leadership in both Fortune 500 and startup companies. She has a wealth of hands-on project experience from the smallest project to projects whose budgets exceeded $50M per year. Jessica holds a BBS in Information Systems, an MS in Decision Sciences and has a current PMP certification. Jessica runs Project Management 101, a blog dedicated to discussing various topics about Project Management.