financial forecast. I am going to continue to use a project schedule and publish status reports even if no one reads them. And if Vijay continues to tell me to stop doing what I know is right then, like Jim and Rick, I am going to search for another job.
Another best practice is change management. Change management and configuration management are two disciplines shared by projects and operations. This company has a rigorous change management process, but they ignore it. Requirements are in constant flux. Rick, Jim and others have asked why my employer accepts fixed price contracts with no restrictions on scope. My response is that this is a natural reaction to the environment we inhabit. Every behavior that we choose is chosen for a purpose. Vijay put this proposal together and he is convinced that we will make a profit. The numbers show otherwise, but Vijay is content to ignore those numbers. Vijay, like many executives, has developed the ability to selectively hear only good news. And when there is bad news the fastest response is to shoot the messenger. I have worked for numerous companies that behaved exactly the same. Those companies see no advantage to best practices and they never will. Unless and until you see a clear distinction between where you are and where you can be there is no motivation to change. As long as all of the problems that arise are simply swept under the rug nothing will change. As long as we adopt the attitude that there is a linear causality between the person and the results then we are doomed. Consider Vijay's response to the problems on this project. He wants me to update a process document that no one uses. First, best practices are meaningless if all they are is paper sitting in a file cabinet. Second, this is a system. Pushing on Luke will not solve the problem unless we can also influence Kathy. We do not need more processes. What we need to do is follow the processes that have already been defined - starting with change management. Change management would allow us to manage the requirements. And if we could manage the requirements then we could deliver the right product.
By now you probably sense my frustration. We are not striving for vision. We are not following best practices for projects. We are ignoring the processes that are defined for operational consistency. But the topic that is the most frustrating to me is the way we ignore all the other rules and then blindly feel compelled to pretend like governance matters on this project. Governance, on this project, means that I am obligated to devote hundreds of hours to the creation of thousands of pages of documents that will never be read. Process, solely for the sake of having process is worse than meaningless. All of those hours I am now spending on useless documents is taking me away from tasks that could add value. I hope that nothing that I wrote in my chapter on governance is ever used to justify such nonsense.
Now, if I was not spending so much time on those useless documents I would instead spend more time on metrics. I look back now at the metrics I used on prior projects and I dream of putting them to use here. Failing to do so is, I believe, the root cause for most failed best practice initiatives. My goal in analyzing metrics is to find early warning indicators. Seven points on a control chart trending upward is an indicator. Lines on a cumulative flow diagram diverging or converging is an indicator. Find the warnings and take action before they become problems. The key reason I do not believe that best practices will ever occur here is that we are resistant to metrics. I used metrics to warn that our budget was trending negative and I was told to stop publishing. I persisted anyway in trying to get Vijay to accept the reality that we are no longer trending towards negative numbers but we are rampaging through red ink. The result was a direct order that I was to stop collecting the metrics.
This is a personality weakness in people who are strongly motivated by power. They do not want to see the evidence that their decisions do not get translated into the desired results. There is nothing wrong with that motivation. It is a part of the human mix and it serves a purpose by allowing visionary optimism to persist in the face of statistical forecasts of doom. But managers need the ability to discern. Managers need to be able to listen to the bad news. To an extent this means that managers need to be versatile enough to use the different styles of management such as telling, selling, participating and delegating. To an extent this means that managers need to have a high enough emotional quotient to be able to know to whom they should listen. To an extent this means that managers need to be mature enough to seek the good of the group instead of focusing on self.
Now I am adding to that list. Now I see that we each need to step out of our comfort zone and engage with the variety of motivations. Always taking the power path leads to the fad of the month initiatives. Always following the achievement motivation leads us to seek a state of perfection that is as meaningless as an unread report. And if any of us neglect the affiliation motive then we will find it difficult to lead the alienated.
What I want to find is a work place ecology where the parts are aligned and people are valued. I guess that means I am going to need to build it myself. I have a vision that this tiny little project can demonstrate best practices. I now realize that the best way to achieve governances is through roles and communication structures not through documents that go unread. I am going to use the best tools that I know of to manage this project - but I will not distribute those documents to those that do not have the ears to hear what I am saying. I am going to continue to measure the indicators that are the most critical to me. I will not, however, share those metrics with anyone besides Greg.
Most importantly, I am going to set as my goal the creation of a repeatable process that will allow this project to work smoothly and deliver consistent results.
Testing the Fifth Deliverable
Mahesh struggled to get closure on the fourth deliverable and he did not understand why I did not send more of that work back to Sanjay and Srinivas. I explained that this is a critical path issue. There is a lot of work required for the fifth deliverable and if I disrupt their concentration then Sanjay and Srinivas will not finish on time. Instead I am disrupting his schedule. He is not on the critical path for this phase and thus I can allow his work to be delayed without impacting the project completion date. As we talked about this I realized that the concept of critical path is a learned concept. I began using critical path when I was a teenager and I just assumed that everyone else learned it at about the same age. In the past I was surprised when people would pull me off my assigned work and give me responsibility for coordinating their projects. Forty years later I finally understand that the concept of critical path is not universally acquired. Now that I understand that the concept of critical path is a mental model that comes with some assembly required, I will make it a point to help Mahesh learn this concept. He is one of the people that will shape the future of this industry and now is a good time for him to begin to visualize a critical path.
I then initiated a campaign to change the direction of this project. Sanjay and Srinivas like to do excellent work and they like to hold onto their code until they are satisfied. I need them to give me their code while it is still premature. I lobbed over a few polite requests and we talked about it on several phone calls. But when they politely ignored my request I lobbed over a more volatile email. It got their attention and the hornets started buzzing around looking for who had dared to disturb their solitude. I spent time talking with Vijay and lots of time talking with Sanjay and Srinivas. Still they held onto their code. I wacked the hornets' nest a couple more times and tried to help them understand that I was turning their world upside down. And then they got it.
One of my favorite management books is Spencer Johnson's Who Moved My Cheese: In that book he tells the story of a few individuals that adapt quickly to change and a few individuals who prefer to opt-out. Sanjay and Srinivas, like the heroes in Johnson's book caught on quickly. I had to prod them a bit, but as Johnson put it:
“One morning they arrived at Cheese Station C and discovered there was no cheese. They weren’t surprised. Since Sniff and Scurry had noticed the supply of cheese had been getting smaller
every day, they were prepared for the inevitable and knew instinctively what to do.” (Spencer Johnson)
Sniff and Scurry - the heroes in Johnson's book - knew immediately that it was time to go search for fresh cheese. Srinivas and Sanjay needed a few gentle reminders but within a couple days they were off and running as well. The old process was dead. The new process required a different approach to the work. They got it.
Vijay, however, still did not get it so Greg called a meeting. I explained that the way we had been working had led to the failure we saw on the fourth deliverable. I explained that rapid turn-around of code was the best way we could hope to get accurate requirements and thus deliver what was required. This puzzled Vijay. He could not see how doing poor work quickly was going to lead to good results in the long run. We talked for a while and then Vijay decided that the solution is to convert my test scripts into a simple checklist. Rather than listing all the steps required to execute each test what I need to do is just make a list of tests and count on people to figure it out for themselves. This puzzled me but
Workplace Ecology: A Case Study in Project Management Page 7
