Too Many Rules Mean Something Is Wrong With Our Project Management
We had the premier project for the organization and we were determined to finally get a product out on-time and with good quality. We did it, and in doing so highlighted how many of our rules were not really helping us to complete a quality project.
Our first major milestone was to pass the criteria to start fully integrated system test. The normal procedure was to start “testing the water” of how well the product was doing at about six weeks prior to the point we had to pass the quality criteria. We had changed that time period significantly with an improved schedule by having observed that previously the six week period actually ran something like twelve weeks. Since we had set a realistic overall schedule, we had the time to put in a period of twelve weeks for the duration of getting all the development integration issues worked out without impacting the overall schedule.
This period of time leading up to this system test readiness milestone was always one of the most intense times in any project. It was always a mess and we always, yes always, never passed the quality criteria for starting system test. Instead, we continually “reinterpreted” the criteria or limited the evaluation period to some arbitrary time where we would have few enough defects that, for the moment, we could pass the criteria.
This time however, while it was still very challenging, we passed just about all the criteria with a fair amount of breathing room. To do this we had to stop the teams from applying all the “interpreted and compromised” criteria. I, as the project guy — who supposedly benefited from modified criteria — had to insist that nothing be waived or interpreted and that we apply the full criteria to the full period. Even the test and quality folks were shocked at my request. These folks were usually the advocates of using the full criteria while we — the product and the development teams — were usually the “we want an easier interpretation to meet our schedule” demanders.
We passed the system test readiness criteria. This was the first time any project passed the criteria on the first try. My boss who had been doing these kind of projects for many years and had all the premier projects in the company said it was the best results he had ever seen at this point in a product’s development.
The point to all of this, without going into the details of the quality checklists, was that once we did away with the real problem — the unrealistic six week schedule in this case — many of the quality review checklist items that had been built up over the years became irrelevant. They tested all sorts of criteria to ensure that the product was ready to move forward, but in fact these checks were just in response to a compressed schedule and everything that could go wrong from such compression. We can break any process, and we did most of them, by just scheduling too little time. These checklists ultimately made no real impact in helping us to combat the root cause. Instead, a culture of “adjustment” arose around them and negotiations and political arm twisting were the key activities during this period, and not how we could improve the quality of the product (i.e., we argued about the checklists and their meanings and not the defects).
If our reaction to problems in our projects is to add more rules and more people to look over the shoulders of those doing the work, then we are probably not dealing with the root causes of the problems. If the problems seem centered in “people just keep making mistakes” then we need to take another look at the overall process and see what is really causing all these capable folks to make mistakes. Fixing the root cause will reduce the mistakes and also lessen the number of people and rules we employ to try and fix these activities.
Do all your project management and quality rules add real value?
1 thoughts on “Too Many Rules Mean Something Is Wrong With Our Project Management”
Comments are closed.
Comments from around the web:
HARISH JULKA, Mohammed Abdus Samad and 1 other like this
Roberto Guandique • I believe that there are Project Managers and Project Bureaucrats. These last ones are really interested in making sure that every “i” is dotted and the complete methodology is followed. Project Managers are more interested in the execution of the project; they are interested in applying what is needed and use their expertise to use relationships and interpersonal skills to monitor the project.
I have seen the Bureaucrats create bad experiences with clients and Project Teams.
Having said that, I believe that Project and Program Governance are important and should be followed when they do not interfere with the performance of an efficient Team who have shown proper diligence in the execution of their tasks and satisfy the Clients. Governance if well defined and managed can improve processes and help the Team to meet common goals and achieve business objectives.
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • @ Roberto – well elaborated. Who needs the pen-pusher mentality when trying to make a success of a project?
Yes, there are certain rules that must be respected for health and safety, etc. but …… sometimes there is just too much bull that obstructs progress.
Bruce Benson • Roberto,
I often try to update the process when what is written or specified doesn’t match what we actually do (should do). Sometimes this works, but too often I hear “why waste time doing that, let’s just do what needs to be done!” The problem is that we get so out of sync between governance and actual execution that we lose whatever benefits the governance is intended to provide.
The other thing that happens is in updating the process I try to remove those things we no longer do (don’t need to do), and I inevitably get push back by folks fearful of removing anything. “Do you know what this governance section means?” “No, but I don’t think we should remove it, it might be important!”
Tis never easy, but I’ve always found it is useful to spend some time keeping it all in sync.
Good comments.
Bruce
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • There is a big difference between heavily prescriptive processes and a lighter weight and flexible process for governance.
Most of the template driven processes provide for pragmatic adaption to circumstances and should be used as a guide as to what can be included.
There is little or no value in producing huge amounts of documents that no-one will ever use, but there is a need for easy to use reference material that will help project team members to produce the right stuff at the appropriate times in order to satisfy governance requirements.
We have probably all seen large projects where there is a team of pen-pushers who produce and maintain a library of deliverables, often without knowing for what they are used. I have never measured the success of a project by the weight of the documentation, but I know that in the public sector the success of a project is often measured by peers and government stakeholders by how well it has complied with the processes rather than by the quality of the product or service that the project has delivered. Several public sector bureaucrats have told me about their experiences of this phenomenon in various countries; so it is a common mind set that exists in the public sector.
Bruce Benson • Dougal,
I’ve seen this too. I’ve observed that when an organization doesn’t perform all that well or what it does is very indistinct (what are you doing and why do you do it?) that they often have what I consider “created” measures of success. “99.99% process compliance” looks pretty good until we try to find out what are the benefits of that compliance.
Our IT organization proudly stated that their communications lines supporting us were working 99.99% of the time. The quality was often so poor that nothing could be communicated over them. One of our folks who had worked for IT fixed the problem for us. He turned off the link and reported it as out of service. He would not agree to a “working” status until the quality was good — all the time (I think he insisted upon a week, if it went poor – even for a minute, he would switch the link off and the week count would start again). Drove IT crazy, but it highlighted how their metric was being abused and encouraging low quality by the desire to say “but it is connected!”
Bruce
http://Facebook.com/ProjectManagementToolsThatWork
Roberto Guandique • Thanks Douglas for your comments I love the term “pen pushers”….
Bruce, in your comments I can see many, many things that can be discussed. For matter of brevity, I will address the point of “why waste time doing that, let’s just do what needs to be done!”….That is the key; always do what NEEDS to be done. This means exactly what the words mean. Do what you NEED to do to accomplish a successful project to the satisfaction of all your stakeholders.
Sometimes lack of communication between stakeholders and the PM creates the expectation that you (the PM) have to document everything, even the trips to the restroom, when in reality that is not the case. Remember rules are a double edge sword. If you follow them to the “t” you might have something to CYA and at the same time – something to “maybe” add overhead to your work.
When you are an internal PM of the Organization I can see how this might present a problem, especially if you know that documentation is done to only collect dust. However, when you are a consultant PM (external to the Organization), it is wise to follow the Governance to the “t”, especially if you know that that will help you in documenting everything on the project. Sometimes, you, as an external PM need to add more documentation because some organizations do not have good governance procedures/processes/rules in place to document their Projects and, you need to do it to prove your value in effort, time and cost.
All Governance is good, if it was designed to meet the specific needs of the enterprise at all times. We need to exercise good business acumen in the execution of all the Projects that we perform. Not everything that is done in the execution of Projects needs to be followed because you have to comply with a rule.
My recommendation to Junior PM is to do a “reverse stress testing” on rules. Answer the following question: What will happen if we don’t follow these rules and what will be the impact on our Project? If you don’t see any impact to any stakeholders’ expectations and the quality of your deliverables it might be a misinterpretation and you should ask the Sponsor or any of the main stakeholders about the rule to clarify your mind.
I am pretty sure other experienced PMs have lots to add to my comments.
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • @ Roberto – Pen Pushers is the term used in some places in Europe and maybe elsewhere, but in lots of Europe the term is paper pushers. Take your pick and I believe that most people will understand as so easy to translate into other cultures.
I loved your “trip to the rest-room” analogy. According to folklore, Fortis Bank, records the time thinking people take for smoking breaks, as if one stops thinking about a problem when one leaves the building or goes home at night. To be fare to Fortis, it is probably the result of some old agreement with the unions, but it is irrelevant for people who work away from a production environment.
Similarly, the CYA mentality fits perfectly. Produce XYZ docs and everything will be fine, even if the content of the docs is complete sh*te. I have lost count of the number of times when I have checked the document repository and found stuff that was there that came from another unrelated project, but which had been renamed in order to satisfy the requirements of the document check-list (does the film “China Syndrome” ring any bells?)
Because of the ass-licking mentality that persisted throughout the Indian Army at the time and which exists to a large extent in Indian businesses today, when my Father wanted an opinion about how well something had gone, he started asking the most junior officers first, to prevent everyone ageeing with the boss. Always a good trick and something I have never forgotten. The same situation existsin so many cultures and it is relevant in a similar way the to the manner in which we produce documentation for projects.
Fyi – my father was not a military type, but was obliged to be part of the Indian Army Reserve as part of his contract of employment. His day job was a plantation manager and for most of the period after WW II ran a 600 square km plantation with some 3,000 workers, but retained the links with the guys with whom he had served during the War and so there was a frequent exchange of info about situations.
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • @ Bruce – sorry for responding out of sequence.
Your posting reminds me of the expresssion “Lies, damned lies and statistics.”
We all know that we can cook figures to provide an answer to almost any question.
Here, my partner and I produce the monthly newspapers for the 2 communities in the area, comprising 28,000 inhabitants, approx. As a consequence, we hear the local Police, area bureaucrats and politicians provide all sorts of stats to support and promote their various levels of activity or justify their positions as appointed or elected officials.
Obviously, there are all sorts of reasons for presenting the stats in preferred ways, but one needs to be able to see underneath the surface to understand what has been happening and to know what has been included or ignored.
We have been producing the 2 publications on a monthly basis for 6+ years now and it has opened our eyes to the cheap tricks that are pulled to hide bad or less good news. The tricks are pulled on every front by almost every player; so if one multiplies this upwards to the national level the smell is overpowering.
In business, even in the binary world of IT, the figures are massaged to present whatever picture the decision maker wants. As part of my day job, when working for others, I plead guilty to answering probing questions on projects in difficulty by saying things to the effect, “I have no info to indicate that the project is in difficulties.” etc. in the full knowledge that my immediate superior is running round like a headless chicken trying to fix a zillion problems, any one of which could explode imminently.
However, when I am the auditor, the shoe is on the other foot and I know how to ask the sorts of forensically probing questions that require a much more precise answer for which my response in the previous paragraph would not work.
D.Glen Jackson MBA/ PM & GEM • Dougal, In an old venacular, it was “Pencil-pushers”.
And, please speak and spell the word (statistics) correctly. Is is Sadistics!!!!!
Douglas (“Dougal”) Lawson (douglawson@btinternet.com) • @ D. Glen – love your deliberate typo.
Do I have your permission to re-use it when explaining “stuff”?
D.Glen Jackson MBA/ PM & GEM • No typo!!
And you have my permission to use as appropriate.
With or without crediting your source.
David (中岳) Liu • I like what Roberto said – ““reverse stress testing” on rules”. My project managers asked me “why they need create deliverables according to the project execution system I made, that is an additional paper work”. My answer is that they should consider the PE system as a guideline instead of a rule, and they need to understand the purpose, methodology, and even values behind the PM system. If they want to skip an activity or a deliverable, that’s OK, but they are expected to ecpain “why” to show they are really understand their job. One of my colleage said that a rule is made to be broken. I like it. Actually, we need always ask ourselves what is the purpose for which we need a rule. If the purpose does not exist, the rule can be thrown into a trash can. Welcome your comments.
Bruce Benson • David,
“need to understand the purpose, methodology, and even values” – absolutely. Too many people follow “the rules” with a checklist mentality (the more I check off, the better I am doing!). We need to understand what we are doing and what value it adds. If it does not add value in a circumstance, then don’t do it.
Bruce Benson
http://PMToolsThatWork.com,
http://Twitter.com/BruceWBenson,
http://Facebook.com/ProjectManagementToolsThatWork
David (中岳) Liu • Thanks for you links, Bruce. I totally agree with you that one of key project execution purposes is value added. Above we talked the value added, purpose, methodology about project execution. Also, I think a rule as an agreement that stakeholders consent to and follow. If anybody queries the rule, relative stakeholders should get together and check if the base on which the rule is built are still existing, or has changed. Actually, if a rule can not be respected by stakeholders, they will try to break it and it is not efficient for project execution, even nor worth to exist.
Tim James • @Roberto
“All Governance is good, if it was designed to meet the specific needs of the enterprise at all times.” Don’t know for certain that this was tongue in cheek
No set of rules can meet all the requirements of the enterprise at all times.
Governanace can be Good
All Governanace can sometimes be Good
But All Governance is Good – no.
There has been discussion of why “things” should should be considered for “languish pile” from the project perspective but not enough from the enterprise level.
Follow the money – who uses the information, what for, and what is its value to those that use it. Finally could that value be generated more effectively by other means of data collection …
Reminds me of not too distant discussions of When to abandon a Process.
Roberto Guandique • You are right Tim……..all governance is not good;, only IF…