Emerging Tech

Monitor project progress by using micro-deliverables

Micro-deliverables allow you to effectively gauge the health of a project. Paul Glen offers four simple rules to follow when planning for and using micro-deliverables.

Too often failing projects surprise us. Have you ever had a project that seemed to be going along just fine, and then, when the delivery deadline drew near, suddenly, everyone's two months late? It leads you to wonder, "How could I have missed that this project was two months late?" "What planet was I on where this project appeared to be on time?"

Given that approximately three quarters of all technical projects fail to meet their schedule, budget or feature set goals, you'd think we would be better at spotting groups that are "off the rails." The reality is that determining when a project is in trouble is not an easy thing, and problems that seem obvious in hindsight are murky at the time that they occur.

Monitoring project progress is an important part of a leader's role. Knowing when and how to intervene in failing projects is critical to the overall health of any technology organization. Whether the intervention is to cancel a hopeless effort, or to correct team skill or resource imbalances, managers need to spot difficulties early in order to prevent issues from becoming disasters.

Of course, projects don't really slip two months in one day. They fall behind a little every day, and the slippage accumulates until we notice it. So the question is how can you notice the problems and fix them when they're mole hills rather than mountains?

Most project methodologies call for monitoring task progress, budget tracking, and hours observations to check on the health of a project. Unfortunately, I find that these are inadequate to gauge real progress. Estimating task completion is notoriously subjective. The last 10% always seems to take 80% of the time. Counting hours expended has nothing to do with real progress. Effort rarely equals results. Although knowing how much of your budget has been spent is important, any positive correlation between the percentage of budget expended and percentage of project completed is generally coincidental.

The best method that I've found is to use what I call micro-deliverables. Most projects are planned with series of tasks that lead to major deliverables, the documents, deployments, or code that the tasks create. But these deliverables are usually the result of many people's work over a period of weeks or even months.

Micro-deliverables are much smaller, individual efforts. When you plan for micro-deliverables, each person on a project has responsibility for some physical product every few days. Then you can gauge the health of the project by checking whether the micro-deliverables are done or not. You don't have to wait for months until a big deadline looms to check the health of a project.

When planning for and using micro-deliverables, there are a few simple rules to follow:

1. Never let anyone go longer than a week without owing a micro-deliverable.

Any time a person goes longer than a week without a deliverable, they go into a black hole of unknown progress. You can't really gauge how they are doing, and you are more likely to be surprised.

2. Micro-deliverables are either done or not done.

When measuring progress, there are only two states for micro-deliverables. They are either 100% complete, or they are 0% complete. Progress is marked only by final approval of the item. Otherwise, you get into the subjective world of guessing how close to done things are, which is inevitably inaccurate.

3. Progress is not measured in effort, but in micro-deliverables.

The only meaningful measure of progress is whether micro-deliverables are done on time or not. If they are coming in late, the project is late. If they're on time, the project's on time.

4. A micro-deliverable is the responsibility of only one person.

If the deliverable is owned by more than one person, it becomes a problem to figure out where the real difficulties lie.

Using these simple rules, you can begin to identify project problems quickly and accurately avoiding the surprises that are otherwise all too common.

16 comments
andre
andre

in old times we called it Manageable Work Unit - the length depended on size of the project,uncertainty, risk, skills and so on. Today it is called Scrum's Sprint, tomorrow will be called....

Steve Romero
Steve Romero

I like the idea of any convention that enables me to accurately understand the status and health of my project. If knowing the status of your project is a challenge, then micro-deliverables may indeed help. My concern lies in the question of "What next?" As with any metric, or any information for that matter, its value is derived by our ability to use that data to make decisions. This micro-deliverable method provides a "flag" to let us know if something on the project is not going to plan, but what are the next steps? For example, a micro deliverable may be late, but if it is not on the project's critical path, it may not necessarily have an adverse impact on eventual project success. I may actually waste time and resources by tending to a late micro-deliverable. Identifying and monitoring micro-deliverables is a clever means to understand project progress. But additional analysis and understanding is required to adequately respond to the information micro-deliverables provide. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

PunkRock_PM
PunkRock_PM

My almost 15 years of IT experience has never provided an opportunity in private or public sector work that allowed a team the luxury of adequate planning time to enumerate and document micro-deliverables. We only resorted to that tactic if we had a junior level person, or someone new to the project, and it was hopefully temporary. Our time constraints compelled us to stay focused on the higher level major deliverables and milestones. I am not saying this approach does not work. I'm sure it does because clearly, the better job done planning, the better the results. Micro-deliverables can't happen without planning. I am concerned that the approach is too easily twisted into a cudgel by which to beat the team about the head and shoulders over minutia that does not really add value. The wrong things can be mistaken for micro-deliverables of value by those not intimately familiar with the nature of the work. I'm sure there's an immense amount of PM and team satisfaction in saying we completed X number of items from the task list on time this month.

sutyakk
sutyakk

This is at the very crux of delegation. Great idea. But, weekly may be too often for the micro deliverable - it should depend upon project length and complexity of the micro deliverable. Remember, if you want something real bad, then you'll get something real bad. It is easy to misinterpret what is being said here. All too often I see meetings and project updates at a frequency that creates an impact on man hours in the work place. I believe the author is not talking about update reports, but is stressing the need to break down projects into palitable micro-deliverables (i.e., How do you eat an elephant? One bite at a time). Thus, the micro-deliverable should be related in some way to the development, improvement or implementation of the project at hand. And, assigning a routine frequency such as "weekly" leads to creating extraneous micro-deliverables and collaborations, all of which take time - time better spent on the project.

kriebela
kriebela

Essentially what Mr. Glen is describing here is Scrum, but Scrum is ever more effective because it makes the team own deliverables every day. I personally think that a week is too long to go without updates.

malacrida.luigi
malacrida.luigi

I'm working in IT Project Management for a long time and I cannot be more in agreement with this approach. IMHO some of the most common Sw Agile Methodologies (like Scrum) are based on the same principles: simple tasks, defined owner, known acceptance criterias and short-term review meeting to monitor the status.

Jesper Ernst
Jesper Ernst

Whats the effect on the ammount of Project management hours when trying to implement this Micro Management ? Regareds Jesper Ernst

tim_birch
tim_birch

As an IT PM of over 10 tens year I fully support this strategy. Although, I would like to make the following comments: Firstly, most projects don?t fail because of technology. There?s generally another reason (scope, management, skills, etc?) and this strategy should highlight the underlying problem. Secondly, about point 4 ? I couldn?t agree more. No task should be delivered by more than one person. The topic area here is WBS.

dlchilton
dlchilton

As a relatively new PM this sounds like an excellent idea. Can you provide some real world examples that can be discussed?

ShaneHo
ShaneHo

I fully agree with this principle. When I worked in MSFT operations, the rule of thumb was that any project task would not less than a half days work and not more than five days. Anything larger than five days should be broken down into sub-tasks. It is also essential that task completion is tracked at 0% or 100%. Entering partial percentage complete numbers is meaningless, unless you also go the effort of tracking hours spent, hours remaining, budget spent and budget remaining to facilitiate a full 'earned value analysis' calculation. I came across a very slick web-based PM system recently which is apparently implemented in a number of large sites (public sector and private sector) which tracks task progress by a simple 'percent complete' number. It then takes this unreliable, subjective number and rolls up a fancy calculation to give an overall percent complete figure, which is of course completely meaningless.

brian
brian

I disagree completely with your comment to fire people if you need to implement micro-deliverables. I am an IT staff of ONE. I get pulled in 75 different directions all day. Seriously, it has taken me an HOUR to finish an e-mail to a person (ID/Password/URL) because of so many interrupts. I've had 5 different people interrupt me in a four MINUTE span. With this many distractions and reprioritizing of tasks, I have to constantly back burner my projects and return to them later. Having a microdeliverable list provides manageable chunk to deliver "when I can." Putting deadlines to them every week gets them done, so I don't lose myself with the day-to-day minutae.

sledgemdi
sledgemdi

A practial, but not realistic solution. In some organizations, including most that I've worked in for the last 25 years this simply can't be done, can't be done easily, or worst, if it can, you're left without the ability to add replacement resources to backfill.

theatop
theatop

Micro-management becomes a whole lot harder when managing a portfolio of projects and utilising non-dedicated resources. When resources are constantly being reprioritised or pulled in ten directions the schedule may end up in the bin quite early (despite due diligence up front). There's a large degree of trust involved in managing staff and projects in a matrix environment and I'm not sure if micro-deliverables are always going to be compatible with that milieu. A good principle for some projects though.

wuchak
wuchak

Probably much less than the time they would have spend doing crisis management when they discovered things were way off track. This just shifts some of that effort to a more productive and less stressful task.

ramkip
ramkip

I was wondering what are the other activities that the project manager needs to do. As far as I am concerned, a PM has to do the following - - Planning - Continuous replanning may be required if the things are going bad - Tracking - Tracking the micro deliverables is the best option. - Management of effort

Editor's Picks