The 4 D’s: A Project Management Guideline

The 4 D’s: It’s No Longer a Failing Grade

shutterstock_164555747

I’m certain we’ve all been there before. You’re in the middle of a project, and chaos seems to have erupted. Project changes are coming right and left, your budget is shot, the customer is hammering you with questions on status, the delivery date is closing in fast, and it feels like a freight train heading your way. How the heck did it all come to this? What went wrong? More importantly, how can it be avoided in the future? The answer is the four D’s.

Coming from a software development background, I have always worked with the 4 D’s. However, these principles do not just pertain to software development, rather, they can be expanded into almost any industry that you’re working on a project for.

So, what are the four D’s.

  1. Define
  2. Design
  3. Develop
  4. Deploy

1. Define

This is the foundation phase, and one that, if not done properly, can lead to the project collapsing in on itself. In this phase, you are working directly with your customer or project stakeholder to gather the requirements of the project. The goal is to be as absolutely thorough as possible. However, don’t stop with just the stakeholder. You need to also talk to the end users, and anyone else that might be related to the project. In this phase you must gather as much information as possible in order to avoid missed scope.

Once all of this information has been gathered, it’s time to write up design and specification documents. Here you must document the requirements of the project as you understand them. Go back to the customer with these documents to review. Don’t worry if you have a few iterations while the specifications are flushed out. This is a good thing, because this means everyone will be on the same page. Strive for a rock-solid project definition.

2. Design:

Now that you have all of the requirements, it’s time to design the actual project. Please note, you are not “building” anything yet per se.

In this phase you begin establishing:

  • Non-functioning prototypes
  • Project plans
  • Budgets
  • Estimated timeframes

In essence, you are creating the documents and plans necessary to actually construct the end project.

Once the plans have been created, it’s time to go back to the customer to review once again. As stated before, this may be an iterative process, and that’s a good thing!

This ensures that the customer is engaged, is still on the same page as you, and it makes constructing the end product that much easier, because you both are now expecting the same end result. Embrace the collaboration!

3. Develop

It’s now time to get your hands dirty and start building. Whether you’re writing a new website, building a home, or sewing a new clothing line, this phase remains same. This is where you take all of the plans you created previously and execute them as designed.

One key warning: do not forget your customer.

Make sure that you continue to provide status updates, because the last thing the customer wants is a vacuum where they are unsure of the status. Also, be upfront and honest. This may sound like a ridiculous thing to write, but I’ve been on many projects where the project manager hid things from the customer, such as a blown timeline, unexpected expenses, or a delay in receiving materials from outside sources. Instead of trying to “make up the difference” by cutting corners, be honest with the customer. Your credibility is on the line, and honesty is always preferred.

Once the end product has been created, it is time to review the product with the end customer. For software, this is where end user testing occurs. For construction, it’s the final walk through. Think of it from back in elementary school: show-and tell.

4. Deploy:

The end product has been produced and approved by the customer. It’s now time to go live. Whether that’s opening up the software application to the user base, moving into the home, or mass producing the clothing line, you now have a completed project. However, your work may not be done quite yet. You should allocate time within the project to fix any bugs that may crop up, but don’t warrant their own project. This is your creation, and it’s up to you to make sure it looks as great as possible.

Why Follow This Process?

You may be asking why should I follow an established process? I haven’t used one in the past. The question is whether you want to be proactive or reactive. Do we install a sprinkler system in a building when it’s built just in case, or throw cups of water at a fire that broke out that we did not plan for? Seems like a silly question, right? However, the results are the same. An adage says “if you fail to plan, then you plan to fail”. In other words, if you spend your time creating a rock solid plan using the Define and Design phases, you will have a far better chance at avoiding failure. The time spent will be well worth it.

Leave a Reply Text

Your email address will not be published. Required fields are marked *