Projects and Dark Matter

Dark Matter

One of the biggest risks that software project managers face is “Dark Matter”. On a software project it is defined as “The entity that we know exists but cannot see”.

It is most prevalent on projects where you require an intimate knowledge of business processes. At the beginning of a project, the Subject Matter Experts are assembled, the scope of work is defined and plan is brain stormed. As a project manager we try to extract every last detail about how we will deliver the scope of work. This typically takes a number of attempts but eventually when everyone has that warm cozy feeling, we agree on the plan and kick off.

Warnings Signs

Some weeks into the project at an update meeting someone brings something to your attention, something new, or an oversight perhaps that could have been captured and planned at the original planning sessions. You take it on board accepting it’s a “once off”, you re-plan, you move on.

Two weeks later a developer or engineer sends you an email stating that they have found something else that they need to do that we didn’t capture at the early stages. You take it on board accepting it’s the second “once off”, you re-plan, you move on.

Two weeks later again a developer or engineer sends you another email or speaks up at a meeting stating that they have found something else that they need to do that we didn’t capture at the early stages. You take it on board accepting it’s the third “once off”, you re-plan, you move on.

Does this sound familiar? Are you making the developers/analysts/engineers accountable and letting them feel some of the pain you feel as a Project Manager?

Managing Dark Matter

When running large complex software project is, it is inevitable that there will be unexpected events. It is important here to distinguish the “known” unknowns from the “unknown” unknowns or Dark Matter. For example during testing you may expect to see some issues or defects that need to be managed. So, you “know” that there will be issues but you don’t know how many or the impact of them – i.e. “known” unknows. Then there are the Dark Matter unknowns – it something that someone completely missed at the planning and estimate phase that needs to be dealt with and will have an impact on the project.

When this happens, you should always ask the question, “How did we miss this?”, and “ Are there any more elements Dark Matter lurking in the background that will surface at some stage. It is human nature that in general people do not like to give bad news but it is very important to encourage the project team to be transparent about all issues or potential issues.

So back to the original question – “How did we miss this?”, could we have approached the scoping and planning phase differently? Did we go into enough detail at that time? You will never prevent all of these items, but you can certainly put measures in place to limit their occurrence.

During the planning phase when you have assembled all the relevant SMEs, and when a milestone or deliverable is identified, list all of the steps and resources required to complete the milestone. Go through the steps at least twice, leave it and come back to it the next day when people have time to think, I can guarantee that someone will add to the steps or introduce some other dependency after they have had time to think.

In GxP (regulated pharma projects) a common source of under-estimation is documentation effort.
For example it is very common to see a single line item in a document named “Design Document” with a timeframe allocated to it. e.g. 5 days.

When you look at the actual time and effort it takes it can look something more like:

Draft the Document – 3 Days
Issue Document for Review – 0 Days
Review wait Time – 3 Days
Update Post Review – 1 Day
Issue for Approval – 0 Days
Approval Wait Time – 3 Days
Approved – 0 Days
Released – 0 Days

So, in this very simple example it would seem that the actual time was double the original estimate. If a deep dive was done into the company’s procedures (and track record) for managing document review and approvals, this would have been captured.

Ownership and Accountability

If you experience a few minor occurrences of dark matter during a project, you can probably live with it. If on the other hand every time you expect to complete a task, you experience another instance of dark matter in the form of new tasks and dependencies, you need to stop, down tools and do a deep dive into the plan. Nobody will want to do this but it I necessary sometimes. Don’t however fall into the trap of follow exactly the same planning method. You will need to do something different. So allocate ownership of specific parts of the plan to individuals. Make it clear that you need their expertise to get int every detail before you can communicate out on another baseline of the plan.

Too often on a project the plan is seen as being the Project manager’s plan – it needs to be the team’s plan and they need to take ownership of their own elements where appropriate. This may be difficult at first but if someone knows that they are being judged on the quality, accuracy and performance of a plan, you will see a different response from the team. Be careful here to distinguish between blame and accountability.

When re-planning, the plan needs to be stress tested by peers and the SMEs to try to break it before you go public with it.

Summary

In summary

Dark Matter exists on software projects.
Don’t ignore multiple instances of dark matter, make the SMEs accountable.
Re-plan differently, learn from previous mistakes.
Stress test the plan.
Look for other potential areas of dark matter.

Further Reading

Other reading – Controlling Scope Creep see this previous blog here

We’d love to hear from you on this topic. E-mail us here