Since my ProjectManagement.com colleagues are hard at work researching, analyzing, and writing about effectively working with and implanting project requirements, it naturally falls to me to do the exact opposite: make the case for abandoning requirements. But I am not doing so simply to indulge a contrarian impulse – there really are times when requirements need to be ignored if they stand in the way of attaining project goals, specifically in implementation projects that seek to advance a capability within the organization.
An anonymous commenter posed a question on last week’s blog, asking how to get the organization out of the habit of comparing budgets to actual costs as a way of performing cost performance analysis, when the organization didn’t even plan very well in the first place. When I read the comment I was reminded of a certain program director who was in charge of over thirty (!) project leaders, each of whom was responsible for a small project, but had no cost or schedule reporting capability. None at all. The organization had no PM requirements and, even if they did, the PLs would not have respected, much less obeyed them. I was assigned to assist this program manager along with an associate from my organization, whom I’ll call Ed. Ed was on fire to write up a series of requirements, attain the necessary approvals, and set out in implement them. Fortunately, I outranked Ed.
At our first meeting with the program manager I brought examples of every type of cost and schedule performance report formats I could find, and asked the PM to select his favorite. He chose what we would end up calling a Bullseye Chart, essentially an XY graph that showed each project’s Cost Performance Index (on the X axis) and Schedule Performance Index (Y axis), with the size of the bubble indicating the size of the total budget. To make it easier to read this already highly-intuitive format, we placed text boxes in each of the four quadrants: positive cost and positive schedule (“Great!”), positive cost and negative schedule (“Get on the gas!”), negative cost and positive schedule (“Get on the brakes!”), and negative cost and schedule (“Trouble!”). As we left the meeting with the PM, I went to work on Ed. I pointed out that, when it came down to it, we only needed four pieces of data from each project to get that report into the PD’s hands:
· Total budget,
· Actual costs,
· Budget by month,
· Estimated percent complete as of the end of each month.
I further pointed out that the first two elements were already available, the third, if not available, could be guessed (level-load the total budget across the period of performance), leaving one measly data point needed on a recurring basis. Ed was having nothing of it.
“What about the requirements? What about ANSI 748 (the standard for Earned Value Management Systems)? We have to verify the basis of estimate! We have to capture their scope in a work package, and establish control accounts! Then we have to issue our own requirements that direct them to use the proper method for collecting their Earned Value! You can’t just collect the data and start reporting the cost performance!”
We informed the PD of the approach we wanted to take to get him his Bullseye Charts, and then communicated the same to all of his project leaders. At the end of the month, we collected our percent complete data (or tried to, at least), generated our reports, and prepared for the project review meeting. What happened next was fascinating.
At the beginning of the meeting we projected the Bullseye Chart for the first set of projects onto the screen, with one added data set: a list of the projects that were not reporting. The program manager spoke to those first.
“Why is your project listed in that category?” the program manager demanded of the uncooperative project lead.
“The data requirement was difficult, and I was really busy at the end of the month.”
“They only asked you for one extremely easy-to-estimate figure, and you couldn’t accommodate that?”
“No, I guess I could. I’ll make sure I get it in next month.”
“See that you do. (Looking at the PL for the next project in the list) Why is your project on that list?”
The next uncooperative PL already saw the futility of claiming difficulty in compliance with the requirements and, like all of the others on the list, apologized and promised the data would be available for the next project review. Sure enough, at the next project review, not only were the Projects Not Reporting boxes empty, but the PLs were talking about their projects’ performance like seasoned PMs. It was a remarkable turn-around – the Program Director was getting his critical performance information, and the quality of that information, as well as the management itself, continued to improve throughout the life of the program. Even Ed was impressed.
And all we had to do was abandon the unnecessary requirements.