The Fine Art of Creating Clarity

If you have ever experienced a project that has gone off the rails, you likely know that mistakes can be very expensive to remediate.?Although sometimes projects get sideways because of completely unforeseen circumstances, often the damage is self-inflicted, or at the very least could have been somehow remediated or avoided. ?The fact is, sometimes we are victims of our own success, rushing through to get done, thinking we know what “Done” looks like. ?Alas, but what if we are wrong?…

The Intent Matters

We all know the sales process can be messy.?Sometimes things are said and promised in the sales process that aren’t entirely captured in the Scope of Work (SOW) handed to the service delivery team. For this reason, it is a ?good idea for the service delivery team to create a document that outlines the intent of the project and populate it with key elements from the SOW, the internal turnover from the sales team, and their own conversations with the key client stakeholders.?

The service delivery team, especially the lead PM and the lead engineer/tech should do their best to understanding the intent of a project.?Be careful here not to capture the HOW of the project.?The WHAT and the WHY are the primary focus. ?This way you don’t start planning to the wrong definition of “Done”.

They can do this by defining these elements:

• Purpose/Objective – What is the primary purpose or objective of the project, and what other secondary or resulting purposes or objectives are there?
• Key Tasks/Activities – What key tasks or activities need to occur in the execution of the project plan?
• Constraints – What constraints are there on time, resources, technology, funding, or other project elements? This is where any requirements and guardrails get defined.
• End-State Vision – What does the completion of the project look like? This is how the service delivery team gets a clear idea of what “Done” looks like.?

Get Clarity at Kickoff

To get the true intent of a project, it isn’t enough to just talk to the sales team that sold the deal and read the SOW (Scope of Work).?You need to talk to the key client stakeholders and tell them your understanding of the project intent. That way they can make corrections and clarifications.

As the saying goes, “I don’t know what I have told you until you tell me what you heard.”

The project kickoff meeting with the client is your opportunity to tell the key stakeholders what you think the intent is, including what “Done” looks like.?The project intent document maintained by the service delivery team gets updated as needed to make it accurate to the key stakeholders needs.?If the resulting service delivery team developed intent document is a different scope or intent than the SOW describes then a change request can be used to bring everything into alignment.

This process of reviewing the intent of the project up front helps ensure there is clarity and prevents the planning process from planning to the wrong definition of “Done”.

Plan to “Done”

With a good understanding of the project intent and what “Done” looks like, the project team can develop a project plan that moves forward in the right direction.?This planning phase is a collaboration between the technical team and the project management support.

In the end, it isn’t enough to have thought out a plan to satisfy the SOW, ?you must be able to demonstrate your plan and show how it satisfies the project’s intent.

This presentation of the project plan is a chance to really impress a client or really flop.?To make sure you are ready for this presentation, you should “Red Team” your presentation with a group of peers who can tell you where you got it wrong. During this process, you would add entries to a RAID log where you document the Risks, Assumptions, Issues and Decisions that you come up with.?

Now you are ready for your back-brief.?All too often a project team will assume they are ready to present their plan, when really they are not ready at all. Practice your presentation at least once before you give it to the client.

Back-Brief Before Execution

The final step in making sure your projects never goes off the rails is presenting your project plan to the key stakeholders. This is where you convince them that your plan is good and will work. You don’t want to be winging it.?Prepare a demonstration that shows them what “Done” looks like.?

Sometimes a back-brief turns into a "Red Team" session and that is OK.?If the client shoots holes in the project plan, tell them you will adjust the plan accordingly and present it again. Schedule another back-brief and adjust the plan. The goal of the back-brief is to achieve permission to execute the plan. You must ask for that explicitly.

Execute

Now execute your project plan, with the Lead PM, and the Lead Engineer/Technician acting as the face of the company with regular status updates and a regular reviews of the task list, the RAID log, and the RACI commitments & dependencies.

A well documented project can be handed to another lead PM or lead technical person and they can continue the service delivery process. If you do not take time to describe how any given project is delivered, you leave yourself open to disaster and low profit margins.?

After Action Review

When you get done doing something, there are six question you should ask yourselves.

They are:

1. What were your original expectations?
2. What actually happened?
3. What went well?
4. What did we learn?
5. What should be done differently for future efforts of this type?
6. What will we do with the information we learned?

This is all I have to say about that.