Lessons Learned #5
- You can't take your eye off of the ball!
You have a lot of good data that tells you something, but no one else will believe the bad news—this situation is all to typical of organizations just starting to use data in decision making (or the first time a new set of data is used). The natural tendency for optimists, or projects that are boxed into a delivery date, is to (pick one)
- Ignore the data
- Reinterpret the data (rationalization)
- Use the data
I've seen people go through all three choices, in order. The first time the data is ignored, because if it were valid, the project would be in trouble, and we can't have that outcome, right? The next time, people know the data is probably good, but in order to meet the schedule, the data is interpreted in a favorable light (as in, "Yes, the defect rate is high, but I choose to interpret that as meaning the early defect removal activities were highly successful, so fewer are left in the remaining test stages"). Now, if the assumption is provably correct, this may be okay. However, if there is no basis for assuming greater success in the early stages, this can be a fatal assumption. When this happens, ask "what specific steps did we take to improve the early stage defect removal? What data indicates we can believe this?" I always add, to myself most of the time, "...other than wishful thinking."
Lessons Learned #6
- You needed training, why not those around you?
Can This Company Be Saved?
Then you run into the real PHMs. I was doing a three-day baseline process assessment. Everyone was cooperating, and we detected a level of enthusiasm among the participants, sort of a "Maybe we can really resolve some problems and improve the way we do business" attitude among the project managers and technical people we were interviewing. We had a final feedback session with the senior manager at 4 p.m. on the third day. He arrived at 4:05 and said, "I have to go to a meeting at 4:30. Can we get this done in ½ hour." (Note this was not a question). You could almost see the people in the room slump in their chairs. Needless to say, this organization never made any progress. (I tracked them on the stock exchange and they fell to ? of their value well before the March 2000 collapse.) Now there may have been a valid reason for the senior manager's early departure (an urgent and unplanned meeting with a key customer comes to mind), but why didn't he say so? Without the reason for leaving early, the rest of the people who had participated in the assessment felt let down.
Lessons Learned #7
- Know when to hold 'em, and know when to fold 'em!
There is a very important point to be made here. The "leave and find a better company or boss" approach to solving the problem just doesn't work very well. Yes, there are some managers in the Lesson 7 category, but the majority fall into the other categories (other than 1), and if you switch companies you are likely to fall into a similar situation. I think if we are to succeed as change agents or improvement agents, we need to recognize the limits of the situation we are in. As often as not, we need to do a better job of tying our ideas for improvement to the business needs of the organization. In most cases it will involve educating those we work with to understand the true value of efficient and effective processes, methods, and practices. Learning to manage with data is not easy, for both technical and culture reasons. Other than the cases where senior management poisons the well, it is up to us as professionals to find a way to sell our ideas, train the rest of the organization, and be sure that at all times we are in alignment with business needs.