Matt Miller is a final year student at Loughborogh University in the UK. He is working on his dissertation on IT Project Failures, and would like your help!

There are 2 surveys below, one for ProjectManagers to complete with details of their most recent 3 projects since January 2005 and another questionnaire for anyone involved in IT projects.

Update – surveys are now closed

IT Project Managers – http://www.questionpro.com/akira/TakeSurvey?id=816578
Anyone involved in an IT project – http://www.questionpro.com/akira/TakeSurvey?id=889253

Anyone who completes the questionnaire would be entitled to an electronic copy of the report and results once the study is complete. When I did it, the last question allows you to enter an email address to get a copy of it when finished.

I recently read a new book by Curt Finch, CEO of Journyx, Inc. titled “All Your Money Won’t Another Minute Buy – Valuing Time as a Business Resource.” I have always been a student of time management, so I was delighted with the opportunity to interview Curt about the book. Please enjoy the interview.

Today I was trying to think of ways to integrate some of the methods and benefits of Critical Chain project management into the traditional PM methodology most companies use. I wanted to pick out one element of CC that would potentially yield the most benefit without much, if any, additional overhead to the project manager. Perhaps this has been written of before, but I haven’t come across it. Most of the CC proponents I’ve come across have an all-or-nothing mentality, so they wouldn’t normally write about this kind of hybrid approach. Here’s what I came up with.

Parkinson’s Law

One of the deadliest risks for slipping on schedule is Parkinson’s Law, “Work expands to fill (and often exceed) the time allowed”. I don’t believe that people on the project are lying around doing nothing because they think they have so much time (like a student might). Instead, people may be doing extra analysis and working on some ideas that might yield truly useful features. Having worked as a developer in a project environment, I can say with honesty that my co-workers and I did this a lot. We were well-intentioned, and we did good work. However, I can also safely say that many of the things we worked on didn’t address a specific customer requirement. They were nice little experiments, and developers love experiments.

The difficulty in managing projects is related to finite resources, time, and budget. Effort which addresses stakeholder requirements directly yield the most value, in that they are fulfilling what you promised. Those deliverables should be addressed first and foremost. If you have time left over, then I’d say it might be OK to work on nice little experiments that may add value.

How can you ensure resources are working on the ‘meat’ before they spend time on desert? I don’t suggest micro-management. That is self-defeating, demoralizing to the staff, and time-consuming.

The Method

Instead, let’s inject a critical chain technique into how you manage this project. Estimates on tasks are usually inflated to allow for slack time in the eye of the estimator. Let’s take the CC method of removing slack and creating a buffer, and apply it to only the lower levels, either on individual tasks or series of tasks. Take the scheduled time and chop off the last 20% of it. (I wouldn’t bother with anything less than 40 hours in duration) This is now your deadline, and the time afterwards until the “official” deadline is the management buffer. Keep communication with the team open and honest, let them know what you are doing. Their goal now is to get the task done by the new due date. If they are done by then, they can spend some time doing “Google-ish” creative brainstorming and experimentation. If not, that’s when the project manager becomes more heavily involved than normal, helping to remove roadblocks and provide more resources. Of course, the PM should be doing this all along, but now is the time to redouble your efforts. It’s important to let the team know that if they go over this deadline, it’s not the end of the world. It shouldn’t even be a negative thing. It’s just an early alert system, and everyone should know ahead of time that there’s just as much chance of going over this deadline as their is hitting it on time or early. Keep the critical path in mind with your decisions, you may have to let a non-critical path task slide to address a critical one.

By managing the tasks this way, resources are compelled to knock out the things that lead to a specified deliverable first, and add the most value. It doesn’t require adjusting the official schedules, or introduce paperwork overhead. This is simply a management technique.

As a solo developer or on a team, I think it would be great to “eat our frogs first” and then either start the next task early, or have a few days to brainstorm about what we can do to add even more value. Working with a team for a short time with a blank canvas, you can pool the skills and do some great team building while generating some really creative stuff. You could also do additional testing and debugging, or start looking at the next task early and brainstorm about the best way to go about it. Or, a little of everything. Let the ones who like engineering do things to fix bugs, enhance the documentation, and make it scale better. Let the prototypers do their thing.

Summary

• Understand CC buffer management and the benefits of it (links below)
• Get your team on board by showing them the WIIFM (what’s in it for me?)
• Keep the critical path tasks in mind for decision making
• For tasks 40 hours or longer:
  • Create a CC deadline by chopping off the last 20% of time from a scheduled task
  • The last 20% is now a management buffer
  • Check status at the CC deadline
    • Not complete: Focus support efforts on the task
    • Complete: Start the next task early, or have a “Google day”!

For some background on Critical Chain and it’s benefits, here are some references for you. Specifically, you need to understand why you’re doing this well enough to get your team to believe in it too. This probably won’t work well with totalitarian rule.

The PM Podcast Episode #57
Focused Performance
The Critical Chain Yahoo Group
Critical Chain and the Design Process – MIT
CC whitepaper from Boeing
More case studies
Yet another case study

I finally got a chance to read this month’s PM Network magazine. There is an article on keeping project team motivated that caught my attention starting on page 38, written by Simon Kent.

The article reminded me of a previous post I wrote back in February, 2007 titled Motivational Theory in Project Management where I laid out some of my thoughts on the topic, specifically in relation to Frederick Hertzberg’s work.

The PM Network article is mostly in line with Hertzberg. Instead of focusing on theory or concepts, the article mostly cites specific examples of how various project managers motivate their teams and keep them that way. I enjoyed the experiential approach to the topic.

Jonathan Bowman cited monetary rewards, and he’s right in saying that you have to be careful how that is done. Team-wide bonuses for early completion or coming in under budget are good ways of doing this. Hertzberg cites monetary compensation as a hygiene factor, not a motivator, and I am inclined to agree with him. Money can be used as a force for recognition however, if directly linked to accomplishments. Personally, I would stay away from giving individual bonuses based directly on project performance. This could provide incentives for people to excel or look good at the expense of someone else and/or the project objectives. Instead, accomplishment should be documented in the performance review process and have their relevant impacts on salary increases.

Here are some of the techniques brought out in the article that I especially agree with:

• Create a team area for co-located projects. Do some banners and sit people who are on the project next to each other whenever possible. This fosters communication and can help create a better team atmosphere.
• Create a learning experience. This one I really enjoyed. It speaks to leveraging strengths of your team members, while assigning them a supporting role in some other area they are interested in learning more about. This way, they can learn without creating undue risk and stress that would come from just assigning them responsibility for something they unexperienced with.
• Use a monthly ‘team barometer’ to gauge how things are going on the project. Joli Mallick, PMP offered this up, and I think it’s a fabulous idea. It’s such a good idea, I’d like to throw out some of my thoughts on how to implement it:
  • Exactly 3 targeted questions, no more, no less.
  • Completed monthly via a website or survey tool of some kind.
  • Anonymous
  • No multiple choice. All free-text.
  • The questions are generated by the head project manager, with input from subordinate project managers and leads.
  • The questions change throughout the project. Using the same questions over and over is boring and irrelevant. A team member gets the sense their feedback is actually being used if the questions are original each month. This shouldn’t be a tracking tool to measure communication performance or something. It’s a direct feedback mechanism for actively managing projects day-to-day.
  • Use a monthly status meeting to review the results and discuss the problems and solutions.

Something like the above would take a few hours each month to administer, analyze, and communicate. It would be worth it though. This is like a Delphi method session each month to highlight the biggest problems and concerns on the project as early as possible. The time spent should not be difficult to justify.

Earlier I announced a contest for a free subscription to The Project Management PrepCast™. We have a winner!

There were only 2 comments where I could identify an email address, the rest of the comments left during the contest were anonymous. I flipped a coin, and Craig Brown is the lucky winner! Incidentally, Craig has an excellent blog over at Better Projects.

Congratulations Craig! Cornelius Fichtner will be in touch with you shortly to get you set up with your free subscription!

This point speaks to the need for
(1) commitment from top management and
(2) commitment from everyone else in the organization.
Quality is everyone’s job, and if any implementation is not total, it will not fulfill its full potential.

In project management, I see this point alluding to executive formation and support of a company-wide Project Management Office. That PMO must be the central source of all project management knowledge, under continuous development by the practitioners of project management. Lessons learned and any potential improvements to the project management methodology used by all PM’s in the company should be evaluated, tested, and implemented as a positive change.

Communication channels and documentation management must be in place so that everyone is completely and totally aware of any changes and how it impacts the way they are to run projects. Feedback mechanisms must be in place to allow those same project managers to make suggestions to initiate their own changes to the methodology.

This also speaks to the necessity for everyone who works on projects to have some knowledge of the methodology. They should at least be familiar with the methodology from an executive summary point of view. They should understand how to use some of the tools and techniques that may be applicable to their contributions on projects.

In order for continuous improvement to become organizational culture, it must also become a personal goal for every employee. Self-improvement should not be limited to immediate application, that would be an example of short-term thinking. Employees are the most important assets of an organization, and therefore require effort to retain and enhance them.

On project teams, the most important assets are the individual contributors that make the project happen. I believe in making all relevant project documentation available to the whole team, including planning exercises and other resources. Explaining your approach as a project manager is key to helping everyone understand the method to your madness, and by example you can help develop organizational and project skills in them. Anyone can become much more productive when they learn and apply many of the concepts in project management. Other skills will come through such as time management, documentation/configuration management, leadership, communication, planning techniques, estimating, and scheduling/work flow management.

If you are a project manager of a permanent group of project team members, you have an even better opportunity to help them grow personally and professionally. On a permanent team, you may even have the power to set aside training time for everyone where they can plan to educate themselves on any topic they wish. This reminds me of Google’s policy of setting aside time for developers to work on their own personal projects without any interference or direction given from management.

Deming claimed that the sense of having helped other people is the most significant motivator and source of job satisfaction. It is one of the biggest enablers for pride of workmanship.

Of the projects you have worked on, think about the ones you are most proud of. What is it that makes you look back and say, “Wow! Look what we did!!!”

Does meeting an arbitrary project deadline set by a sponsor make you proud of the project? Does fulfilling the written requirements even though the customer expectations were not met make you feel like you’ve really done something important? Probably not.

Personally, I feel the most pride when (1) a really significant positive impact was made and (2) I helped people and know they are grateful for what was accomplished. I want people to think and say “wow!” even if it is only to themselves about something the team did, big or small. These criteria are true for me whether I am managing the project, or am participating as an individual contributor.

Project managers should be looking for the great things their teams are doing. People on their projects should know that when they go above and beyond, they will be recognized. A huge part of this is that the PM must be unselfish and there to serve their people. Servant leadership, that is what is required. The PM should start with the viewpoint that the multitude of talent on their team is going to come up with better ideas than the PM can alone, and not be afraid to embrace those ideas.

Another key point is the avoidance of micromanaging projects. Tasks should be broken down to a certain level where the individual contributor can apply their expertise, and no further. Let them execute how they wish based on their talent and expertise. Be there to guide and serve, yes, but not to micromanage. Micromanaging is one of the quickest ways to kill the soul of a project team.

This may be the most controversial point, but in my opinion it is aligned with the rest of Deming’s philosophy nicely, and I agree with this point totally. In the US especially, Management By Objectives (MBO) is very much the status quo. I’ll give a short explanation of my opinion from an operational standpoint first before relating this concept to project management.

In MBO, standards are set for a particular process with the intention of evaluating employee performance by them. Performance in relation to the standard weighs heavily (and is sometimes the only factor) in merit increases, bonuses, etc. A standard example would be handle times in a contact center environment. If the standard handle time is set to 3 minutes, and you are taking an average of 4 minutes, it is said the employee is performing poorly. This paradigm assumes that the measured metric (handle time) is the full responsibility of the employee. Pros and cons of this management philosophy:

Pros

• Easy to set expectations
• Easy to quantify
• Easy to base performance evaluations on

Cons

• Tends to move the focus to being ‘at’ standard
• No focus on process variability
• Tends to make the standard the ‘only’ performance measure
• Provides little incentive to improve processes when the standard is being met
• When defining standards, operational leaders tend to lean towards lower standards in fear of not meeting them
• Propogates the ‘carrot and stick’ approach where fear usually wins out as the strongest motivator
• Discourages educated risk-taking and experimentation with processes, because it might throw people ‘out of standard’ temporarily
• Discourages employees from helping each other by encouraging detrimental internal competition
• Forces employees to try and acheive contradictory goals (”I want to provide great customer service and spend the time the customer requires, but if I do that the way I know it really should be done, I’ll miss my standard and get written up.”)
• Employees and managers may be motivated to skew results so their numbers look better
• Moves focus from customer satisfaction to “covering my butt.”

You can probably tell that I don’t like Management by Objectives. To me it seems like the easy way out, and very much the wrong approach. Deming would say that 90% of defects in any situation can be related to poor systems or the lack of systems in place. Most people want to do a good job and will follow a process when it is well designed and they have the ability to provide input for it’s development and improvement.

Let us discuss this point in terms of estimating project tasks for duration and cost. In the MBO paradigm, what usually happens is that a project team member is given a piece to plan and estimate. Many times there is no process for them to follow in making their estimates. The project manager assumes they are the SME and know how to estimate. The PM may not really have a good idea of how much time they will be able to devote to their project work, alongside all their other projects or daily duties. In many cases an experienced team member is going to throw on a lot of slack time because they are in fear of missing their estimated deadlines. In any case, an MBO mindset is going to lead everyone to blame individuals for mistakes. It doesn’t necessitate a focus on improvement.

What would a Deming approach change? First, there would be a process in place to help guide estimates, evaluate performance to planned estimates, and go back to figure out why estimates were wrong. Another option might be to change the resource load so that a team member can devote all or most of their time to a project for a limited period of time, thereby reducing the cycle time on their deliverables (for your and other projects) and allowing them to more easily estimate in terms of effort required. Part of the process may be to train and guide them in doing a lower level of WBS to break things down into 4-16 hour chunks. It is going to be important in a Deming approach to evaluate tasks that took longer or shorter than anticipated. Not to place blame on the individual who did the estimate, but to find ways to enhance the process of estimating to make it more accurate in the future.

This point consists of two elements as I see it. (1) Walk the talk, and (2) hold systems accountable.

Walk the Talk

Slogans are phony. The word slogan has a connotation of something that is not real. It sounds like an advertisement, and not something you can really trust in. In a project management organization, it is much better to have published guidelines and a vision that defines your philosophy and practice. Train your project managers and teams on the methodology. Then, let them execute within that framework, and put a system in place so that the practitioners can revise the process and make it better.

Additionally, if you say you are going to deliver the product by a specified date, budget, and quality, then do it. Consistently. Estimating a launch and then consistently missing the deadline is a sure way to make upper management believe you are full of it. Sometimes this goes with Point #9; the project manager points the finger at the stakeholders and says “well, it wouldn’t be so late if they wouldn’t have changed their requirements.” It’s your job to fully understand the requirements early on, so step up to that responsibility and stop the finger pointing. If you took the effort to better understand what they wanted, perhaps you could have provided more reasonable estimates. No excuses.

Hold Systems Accountable

If you do not have a common and well-defined company methodology for project management, you must be expecting every project manager to be perfect. The lessons learned from other projects and project managers must be transmitted through osmosis or psychically, I suppose. That project manager “should have known” how to do proper risk planning. If you lecture the project managers, they should automatically be motivate to do a better job right? After all, it was their fault for not being omnipotent in the first place, right?
A better approach might be to have a set of guidelines, tools, and techniques within well defined processes so that a project manager does not have to also be a mind reader. If projects are constantly failing at your organization, it is not because you have a set of lousy project managers (more than likely), it’s because you have no system in place to manage projects.