The Implementation Phase in Project Management

January 18, 2012 | Author: PM Hut | Filed under: Project Lifecycle Phases

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.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

3 people have left comments

I’m curious about this part:

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

This article advocates a strong Waterfall approach for software development, so I’m wondering how you would do this in an Agile manner? Agile teams don’t typically have an “implementation phase.”

Phil wrote on January 18, 2012 - 3:43 pm | Visit Link

I would suggest that agile teams very much do have an implementation phase. The primary distinction is that agile teams transform requirements into functioning software incrementally in short time frames, whereas waterfall teams move requirements through the development lifecycle phasaes in mass. In regards to the four steps noted in this article, I would encourage readers to read the book entitled “How to Sole It” bymathematician George Polya - I beleve his model (define the problem, devise a plan, execute the plan, examine the results) is the core model behind many of models uswd today in engineering and problem solving (eg Demning’s Plan-Do-Act-Check).

William Parker wrote on January 18, 2012 - 4:53 pm | Visit Link

I agree with you in the sense that agile teams have to “implement,” and they implement a very small quantity of required functionality at a time without being handed a requirements document, etc.

But for instance, we start work on a feature. We talk with the business user about the required behavior. We write tests around that behavior, and these tests also design our code. We iteratively write code to satisfy the tests and have constant user involvement for correction, approval, and those, “Oh, I forgot to tell you about this” moments. When all the tests define the required behaviors and they all pass, then that feature is ready for release.

Which part of that is the design phase? Which is the test phase?

So, I don’t really think it’s applicable to think of agile development as really small iterations of Waterfall. There just aren’t distinct phases, not even per feature.

Phil wrote on January 19, 2012 - 10:40 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories