Is your Project Coastline Eroding?
Your project is moving along, tasks are getting done, deliverables are being submitted for approval.
You should be satisfied, right? But you’re not. You have this nagging feeling that things aren’t 100%. You just can’t put your finger on it. Without clear warning signs, you keep going… with a sense of unease.
I recently picked up Kim Vicente’s book: “The Human Factor: Revolutionizing the Way We Live with Technology”, 2004. The book and the author have accumulated many awards over the years. In this book, Mr. Vicente discusses the various design challenges to adapt to “human” needs. It is in the section of Systemic Degradation that I started thinking about some of my past projects. These projects, without going “south” might have gone “sideways” a little.
To illustrate the system degradation, Mr. Vicente applies Rasmussen’s (1997) Risk Management Framework to a 2001 tragedy that affected the water system of a Canadian municipality. (Its mayor, on October 16th, 2018, announced to the media that the municipality was considering launching a project to “optimize google” to make sure that the first results to appear when searching their municipality do not refer to this tragedy. Cost of the project $50,000). In the Risk Management Framework, Rasmussen theorizes that organizations have Operating procedures and objectives that are constantly under pressure. Workload and financial pressures push staff and organizations to cut corners and sometimes deviate from proper and approved procedures. These rogue work practices may become the new normal, especially if the clients and stakeholders don’t notice the change and quality appears unaffected. The model proposes that in these cases, the system can slowly degrade until a time where system outputs reach the Safety Boundary and problems ensue.
What is interesting with this model is that it is simple yet contrary to how we usually perceive how problems occur. Our brains prefer the simplicity of the Domino Effect (Heinrich 1931) where one event leads to another event and so on until the problem occurred. Rasmussen warns us in his model that root causes may be more complicated than a simple linear cause and effect model. The pressures on the operations are coming from different places and attack the integrity of the system much like the ocean eroding a coastline.
In the tragedy of the municipality water system, numerous processes degraded well before the five inches of rain that fell in the span of a week carrying E. coli into the drinking water system. The outcome included seven deaths, 2500+ illnesses with lifelong consequences, the psychological trauma of city residents and roughly anywhere between $64 to $100 Million dollars of expenses (includes replacing the water infrastructure). Examples of process breakdown included: Not following the prescribed water sampling schedule; Not chlorinating the water as per recommended standards (to improve taste as perceived by some citizens); Not fixing a problematic well head that was deemed to be too shallow; Entering fake water sample results; Not reading lab results; Staff not properly trained in drinking water safety standards, etc. None of these shortcomings can be attributed to causing the tragedy, however, their cumulative impact writes the story of what happened in May 2000.
What can you do?
Have you ever felt that your project or process “coastline” was eroding? Without spending a lot of effort, maybe it is worthwhile to create your own project management early detection system (to borrow a phrase from the military). There is ample project data that we typically have readily at hand that can help detect rogue processes on your PM radar. The PMBOK suggests a few measures to track work performed that are well documented (Cost Variance, Schedule Variance, Schedule Performance Index and Cost Performance Index). These can be used as part of your PM early detection system although it does imply that you have established a robust and standard way to estimate Earned Value.
But what other measures could be part of your Early Detection System?
No need for complex control charts, sometimes just mapping data on a regular XY chart or a simple Bar Chart will be all that is required. Here are examples of data elements that you may have at hand that you can start to monitor today (or you may assign one per project team member).
[widget id=”custom_html-68″]
| Data Source | What it can contain | Early Detection Questions to answer? |
| Deliverable Log | Deliverable ID, Date Submitted, Revisions, Date Reviewed, Date Approved, Revision cycles |
Is the number of revisions appropriate? (have you set a limit to the number of revisions you will allow)
Are the reviews timely? (set a target review turnaround time – a week? 3 days?) |
| Change Log (for Waterfall projects) | Description of the change Module Impact (time and effort) |
Are the change requests increasing (quantity and effort)? |
| Action Item and Issues Logs | Description of the action/issue Completion Status |
Are some issues/actions staying Open for too long? Why? |
| Status Reports | Task % complete | Are some tasks staying in the “almost” complete status for long periods? |
| Meeting minutes | Attendance Decisions Made |
Are all the key players attending? A drop in attendance may signal something about team morale or commitment.
Are some team members not attending as they are being asked to work on other projects/operations? |
| Canceled/Rescheduled Meetings | Record of Meeting Changes | Is your steering committee canceling or rescheduling? Are you losing Senior Management interest? |
| Communication Plan & Change Management Plan | Activities and deliverables to engage project stakeholders | How closely are you tracking to your Communication and Change Management Plan? |
| Quality Report (Testing Reports) | Component Tested Defects |
Number of defects per module tested going up? Number of times component being retested |
Not all early detection systems are charts and data. You may invest time in tracking signals that are not by-products of your project work. These activities may be part of your Risk mitigation strategy. Examples include:
- Assign somebody from your technical team to be on the lookout for any changes pertaining to the technologies used by the project;
- Subscribe to various website that will provide insights into what is going on with vendors and stakeholders involved in the project;
- Ask your team to keep lines of communications open with their colleagues in Operations. Are work processes or staff changing that would impact the project rollout?
Key Takeaways
Complex Systems, Projects, and Portfolios may degrade over time.
- They are dynamic by nature. Are your processes healthy, sustainable & documented?
Risk causation is not always linear.
- Issues may occur because multiple little things are not in place or not working
Graph readily available project data to detect trends
- Pick up the signals before they become a problem
Be aware of your reports’ blind spots
- Have more than one way to look at your project data
Do you have other project data points that you like to monitor as part of your early detection system? Please share below and let’s keep the discussion going in the comments below.