The demand for project resources always exceed the supply of resources. Always. Even at the Department of Defense, with $700B, cannot meet the demand for resources.

The key in success in projects is to manage supply and demand. Most organizations fail. Most fail because they simply don’t know the supply of project resources. Or the demand. Other than that, they’ve got it under control!

Supply

The supply of resources is typically people. Organizations know how many people they have. They may make a crude estimate of person-hours available (number of people X 40 hours, for example). This is wrong. This over-estimates the supply. Your employees do not dedicate 40 hours per week to projects even if they have no operational responsibilities. By the time you subtract staff meetings, time off, HR, and training, it’s closer to 30 hours per week.

The only way to accurately measure supply is to track time. Every employee on a project should track their time. Soon, within months, you’ll have a better number for supply.

Demand

Measuring demand is also beyond most organizations. They don’t do sufficient project planning and therefore don’t know how much time is estimated per project.

The only way to accurately measure demand is to track time. Every employee on a project should track their time. Soon, within months, you’ll have a better number for demand. The best way to estimate time for future projects is measuring time on current projects. Your estimates will continually get better. But only if you track time.

I have a friend with a company called Outside the Box Consulting. I joke that my company should be called Inside the Box Consulting. I am completely inside the box when it comes to project management. In fact, I strive to be equidistant from every side of the box. The problems with my clients nearly always stem from outside the box thinking. They think there is some magic wand they can wave for project success. Or they believe they are agile even if they don’t know what that means. They seek to avoid the hard work by seeking outside the box solutions. They usually fail.

My advice is straight from research, knowledge and experience. Project management is hard but it is easier if you follow proven methodologies of scope, schedule and budget management. There are no short cuts to success. Leave innovation for the marketing and design people. Stick with science for project management.

Project saying #22 – the Highlander Rule:

There can be only one.

The name of this saying is from the cult classic, The Highlander.

I use it when assigning action items on a project. Some people like to avoid action items, or responsibility, or work of any kind. One way they do it is by getting multiple people assigned to a task. If it’s Bob and Suzy on a task, that gives Bob an excuse not to do it. Similarly I don’t assign action items to groups such as IT or Accounting. I want to know exactly who is responsible for the work being done. It does not have to be the person doing the work. It is simply the person I am going to ask for status.

So when someone wants more people added to an action item, sorry ” there can be only one!”

Project saying #25:

You can’t start doing something right until you’ve stopped doing it wrong.

As a consultant I am more familiar with dysfunctional IT organizations, ineffective PMOs and failing projects than most people. They wouldn’t call me if everything was ok. I am constantly amazed at how often my clients know they are doing something wrong. It reminds of a famous Bob Newhart skit where he is a psychologist who tells his patients, simply, to “Stop it!” Whatever bad habits or fears they have just “Stop it! Two words, first word S_T_O_P, second word I_T. Stop it.” It really can be that simple.

But I frequently meet resistance. When I see a project not going well and I advise the not-radical idea of clarifying scope, schedule and budget, my clients will complain “can we just let this project go forward?” Umm, no. I say to them:

You can’t start doing something right until you’ve stopped doing it wrong.

Sometimes I also add project saying #19:

The best time to do a task is three weeks ago. The second best time is today.

It is never too late to stop doing things you know are wrong. In fact, it is prerequisite for you to start doing things right.

Project saying #66:

We’d rather do 10 projects 60% correct than six projects 100% correct.

I find that most organizations do the former. When I review an organization’s project portfolio a common finding is they are doing too many projects. Some of the projects don’t align with the strategic goals and should be terminated in any case. But even if every project is worthy on its own, collectively they are too much work for the available resources.

Why does this happen? It’s the fault of management (or managers to make it personal). Too many managers feel their sole job is to get more work out of employees. They resort to adding more pressure to employees by adding more work. The hope is the threat, or actuality, of additional work will motivate employees to work harder. As if employees are a clogged drain and the appropriate amount of force will clear the obstacles and allow a lot more work to get done.

Manager’s also hate to have idle employees, so they assign work to meet 40 hours per week. However, project work is variable. If you aim for 40 hours per week, that ends being the floor, not the ceiling. When additional work is required, during design reviews or testing or launches, to name three examples, employees put in far more than 40 hours per week.

When quantity of work soars over 40 hours per week, quality goes down. Quality goes down because employees don’t have enough time to do it right and testing is inadequate to find the poor quality. (Morale also goes down in this situation as Daniel Pink has explained in motivating knowledge workers.) Unfortunately, it is difficult to measure quality in IT projects during the project (and may be difficult to measure after the project is done). And more unfortunately, many IT project managers are not technical so they would not be able to determine quality in the first place.

Since measuring quality is not an easy thing to do, management reverts to measuring quantity. Perhaps they can measure quantity of requirements, lines of code or user stories accomplished but usually it’s quantity of hours – all too easy to measure and usable by the lazy and unsophisticated. This results in a situation described by 37 Signals founders Jason Fried and David Hansson:

some people “try to fix problems by throwing sheer hours at them…. This results in inelegant solutions.” Workaholics “aren’t heroes,” they write. “They don’t save the day, they just use it up. The real hero is already home because she figured out a faster way to get things done.”

Measuring true performance and developing a culture of quality is hard. So most organizations don’t do it. But they have to compensate for their culture of defining quality down, which leads us to the corollary of the saying at the start of this post:

We’d rather do 10 things 60% correct than six things 100% correct. Then we define 60% as an A.

Organizations that have a culture of only rewarding more have to come up with a new definition of quality. Voila!

Don’t fall into this trap. Do more by doing less. Terminate the least valuable projects and dedicate more resources to the most valuable. Both morale and quality will rise when employees have enough time to do things right.

I’ll be presenting Lessons Learned from the U.S. Health Benefit Exchange Projects at the 2014 PMI Global Congress in Phoenix, October 26-28. It’s a summary of the analyses I have done on the state efforts to implement the Affordable Care Act. Collectively, billions of dollars were spent. Even small states such as Maryland and Oregon managed to spend over $100M on failed implementations. Oregon eventually abandoned their effort and will join the federal exchange. Maryland also abandoned their effort and opted to spend another $50M to buy software from Connecticut.

I cataloged the biggest failures here.

I love Kaplan and Norton’s balanced scorecard concept and I have designed and implemented it several times for my clients. It calls for balancing traditional financial metrics such as cash flow and ROI with three additional dimensions: internal business processes (which I call operations), customers and learning and growth (which I call HR).

If your operations are projects (aerospace and defense, consulting and construction companies among others), then your metrics in internal business processes should be project-based metrics. I’ve developed a list of metrics that companies should use to monitor and improve project performance.

Metric	Description
Schedule Performance	Earned value metric (SPI) or % overrun for completed projects
Cost Performance	Earned value metric (CPI) or % overrun for completed projects
Scope	% scope delivered (by features, deliverables, stories or requirements)
Resource Utilization	% of workable hours (typically 2,000 per year) spent on projects
Quality	Number of bugs or defects
Change Requests	Number of change requests
Change Request Approvals	% of change requests that were approved
Schedule Estimation Accuracy	Comparison of planned vs. actual by task type (coding, testing, etc.) and by person
Schedule Risk	Qualitative assessment of the risk to the go-live date
Scope Risk	Qualitative assessment of the risk of the day 1 feature set not meeting client's expectations
High Risks	Number of high risks
Risk Mitigation	Number of high risks that are "accepted"
Critical Issues	Number of open critical issues
Overdue Issue Resolution	Number of critical issues not resolved by their due date
Staffing Plan	Number or % of planned project positions that are filled
Contingency Balance	Balance of contingency funds still available
Deliverables Performance	Number submitted on time or late, the number of days late, the number accepted or rejected
Training	% of people trained
Customer Satisfaction	Customer and stakeholder satisfaction as determined by survey

I describe the difference between the traditional waterfall methodology with an Agile methodology as the difference of going vertical vs. going horizontal. You can see this in the difference between the two pictures below.

The first picture represents the typical waterfall project schedule. You essentially do all the planning, then all the design, then all the coding, then all testing and then you implement. This is not exactly right – there is usually overlap between the phases (hence waterfall) but this is more or less accurate. I call this “going vertical.”

 

 

 

 

This next picture is how the same project would be done using an Agile methodology. You would take Feature 1 and plan, design, code, test, and, maybe, implement before moving to Feature 2. I call this “going horizontal.”

 

 

 

 

It’s easy to see the advantages of each technique. Agile (going horizontal) enables you to go through all phases early in a project. You discover coding or testing issues on the first go-around so you can improve each iteration. But the downside with Agile is you may discover something while designing Feature 4 that forces you to re-write early functionality. So you increase the probability of re-work but you lower risk of discovering issues late in the schedule..

In the traditional waterfall methodology (“going vertical”), you rarely have to re-design something because you have taken everything into account during the (one) design phase. Of course the issue with waterfall is you don’t discover coding or testing problems until late in the project schedule – maybe too late.

When appropriate, I use Agile since it lowers the risk of a project. However, Agile is not appropriate for many types of projects or in some companies and the majority of projects are still managed using a waterfall methodology.

Many of the PMs that I talk to tell me that they are so, so busy – averaging 50-60 hours per week or more. To be provocative, I say “You must be a really bad project manager.” My point being is that if you are unable to manage your own time effectively, why should you be trusted to manage other people’s time?

To be sure, many people exaggerate the number of hours they work. Averaging 60 hours per week of work is damn hard. I suspect people include their commute in that number. And some confuse at work with work. But I’m sure some people really work 60 hours per week. And that means they are doing it wrong.

My main point is above – why are you so bad at managing your time? I’m positive you did not schedule yourself for 60 hours per week – probably 40 hours (or slightly less) like everyone else on the project. So if you’re scheduled for 40 hours and work 60 that means your estimates are off by 50%! And more shocking is that estimates for how long it takes you to do something are going to better than estimates for the other team members. So your entire schedule is going to be off by more than 50%. Interestingly, the average schedule overrun is 60% (according to the Standish Group).

Assuming your PM is working 60 hours per week, I am concerned that they are either doing menial tasks or the quality of the work is low. Research proves that the quality of work goes down the more hours that are worked. This is common sense – we make more mistakes at 9pm than we do at 9am. Now, if a PM is doing menial tasks (you know what I’m talking about – PowerPoint slides, tweaking Microsoft Project just one more time, etc.), the decrease in quality may not occur or be noticeable. But that is also concerning. As a PM, I work on the hard things – the risks and issues that require concentrated effort and innovative thinking. I can’t be effective if I’m doing this at midnight – my solutions will not be elegant or functional. If your PM can consistently work 60 hours per week with no noticeable decrease in quality then they aren’t focused on the right things.

In any particular year, I work unplanned overtime just a few times per year. (Note the word unplanned – because some IT project work must be done on weekends, I plan to work several weekends per year.) If I see a PM working a large number of hours, it’s a red flag to me.

If your PM is consistently working 60 hours per week then they are doing it wrong.