We need a better way to manage projects. The ways to address the issues we have was time well spent to test and understand them. We developed a list of solution criteria––the elements that any solution to project management issues must meet. These elements came out of a meeting with our senior executives where we discussed the needs of the business and what our team needs to do to meet them. These criteria are:
-
- Projects are on time, every time.
- Cut project duration without compromise on scope, quality, customer service, lead time or budget.
- Show a positive impact within six months, or less, and is sustainable over the long term.
It’s a high bar. And, with this list of criteria, it will trim any suggestions which can’t meet all three. Everyone has ideas about how to improve and we need the best ones as soon as possible. I don’t have time to hear about more MS Project.
Gary, the Software Salesman
Jim, one of my project managers, brings in his friend, the software salesman. Gary is his name. I can’t help but think what he will try to push down my throat. We’ve tried so many different softwares for so many different problems. I’m taking a deep breath to loosen the tightening in my gut.
But, I trust Jim, because he’s come through for me before. I’ll listen, but my tolerance level is low and my bullshit meter is on stand-by.
After the usual, pleasant introductions, Gary says let’s get to it. He says he has listened to Jim summary of our situation. He’s familiar with all the issues in our environment. For example, the original due dates are not met. There are too many changes. There is too much rework. There are many more, but that’s a good enough start. Jim has also briefed him on the criteria we want to meet for any solution we are looking at. I’ll be testing each of Gary’s claims against them.
The Kind of Project Network We Need
Where Gary starts surprises me. One of the fundamental features his software is that it determines the longest leg of task and resource dependencies. It’s not critical path. His method, the critical chain, is a more recent approach. It’s not something that was developed in the 1950’s.
Interesting, someone also not interested in sticking to the conventional critical path method. A point in his favor.
Gary continues to explain that to start building a project network in this way starts with the end in mind.
Who said that, Steven Covey?
Gary continues, each project must have a single goal and success criteria. He says there are a few, key pieces of information we need to start every project, but these come first. He says some people refer to it as a stakeholder analysis. We’ll look at it in more detail, if necessary.
But, what Gary says next is surprises me even more.
An Important Project Network Building Step
He wants to start building the project network from the final task and construct the project network from right to left. The final task is the only task that does not connect to a successor task, every other task connects to a successor tasks.
I ask him why? Why build a network backwards?
Gary says, when we work backwards we are including only those tasks that are necessary as input to the next step. In this way, we find we need much less detail, yet the end result still meets all the stakeholder needs.
He says, it’s helps to repeat this mantra each time before another task is added:
“To start this task (the successor task) what task or tasks (predecessors) must be finished?”
For example, he says, here is a final task objective and the exit criteria for a project he has helped plan in the past:
The goal of the project is––The vendor will buy and install new video surveillance cameras, servers, software and intermediate disk storage.
The final task name is––Install 230 cameras and associated hardware for the City of Dallas video surveillance system.
The exit criteria for the project are:
-
- Complete by August 1, 2013
- Complete a demo of the system and get sign-off from the Chief of Police.
- Support the City of Dallas’ crime reduction goals.
Gary writes on my white board:
To start this task, Install 230 cameras and associated hardware for the City of Dallas video surveillance system, what task or tasks (predecessors) must be finished. He says, Get project sign-off from the Chief of Police.
To start this task, Get project sign-off from the Chief of Police, what task or tasks (predecessors) must be finished, asks Gary. He says, Prepare sign-off documentation.
To start this task, Prepare sign-off documentation, what task or tasks (predecessors) must be finished, asks Gary. He says, Complete the internal QA of the video system.
With a straight, flat voice I say I get it. It’s so obvious now that I see how it’s done. It does take a bit more thought on my part, but I don’t see a flaw in the logic between the tasks. We continue like this until we reach a tasks which has no predecessor.
If I read the tasks from left to right, they sound like a short paragraph in any technical manual we have laying around. Intrigued, I ask, what’s next?
Assigning Resource Types & Estimating Task Duration
I assume there is more to the project, but you get the idea, says Gary, there are only three more key elements to add. The next two elements go hand in hand––assign resources to each task and estimating the task duration. Assigning the resources usually means identify the type of resource best suited for the tasks at hand.
Sometimes some resource types are in limited supply and it’s OK to provide a specific person. But, by providing the resource type it helps improve the flexibility of assigning actual team members. Gary says the software will identify which tasks need to be assigned and when. It will also list the resource type(s) assigned to during planning. When the time comes, the resource manager can check which of their team members are best suited to do the work and make the assignment.
That’s makes sense, I say, very convenient. But, what about the task duration, I ask.
Once again, Gary throws me for a loop––the task duration is only the touch time of the task. The touch time means only the time estimated to do the work content, without interruption, given all the required inputs. No more safety time is added to the task estimates.
None, I ask.
None, he says.
With that answer I look to Jim and ask, isn’t it time for lunch? We are experts at adding safety time to every task. We are experts at hiding the safety time we add to a project so that no one can take it way from us. It’s a way of life around here. It’s how we protect our collective behinds. But, there must be something to it since everything else Gary has presented had made sense up to this point.
A Potential Deal Breaker
This morning was a refreshing change from the typical software sales. Gary understood our situation, sold me on practical ways to start dealing with it, and kept me engaged without showing any software. Gary was in alignment with me about the longest leg of task and resource dependencies. He enhanced this concept by making sure the goal at the end of this leg was clear and contained specific success criteria. And, by working backwards, right to left, from this goal, the only tasks we added were the one’s which needed to be there. Nice.
On our way out the door, I hope this safety time issue isn’t a deal breaker. I was so hopeful. Like I said before, we must put in safety time to protect ourselves from so many things. Only including the touch time for each task duration estimate is the most way out thing he’s said so far.