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.

Up next: Monitor & Control


One Response to Implementation

  1. melanie gao says:

    I love the analogy of the architect building a house! It’s interesting how many parallels there are between building a house and building a piece of software. Thanks for the helpful and well-written article.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: