"Why is it that when you get hired you are no longer the expert?" A chuckle rippled through the audience; however, the woman asking the question was serious. I turned the question back to the audience of director level managers, "Why is this the case?" There was silence. Finally, I proffered that it was management's lack of understanding the skills of the people working for them. "Who in your organization can you implicitly trust?" More silence. It is sad that organizations know so little about the people that they hired—the people on which they stake their company's future.
With the coming of 2011, it is time to reflect on our past and contemplate the future. We think about our families, our friends, our successes and failures; we think about our jobs, our professions, and the world of possibilities. We must reaffirm our ship's direction, stay the course, make corrections, or find a new destination. As project managers, we must look at the recent changes in the discipline and translate those into a plan for our professional development—a plan that meets our needs and the needs of the discipline.
A speaker at a recent conference asked the well-dressed audience, "When is the best time to listen?" As with most presenters' questions, there was a host of blank stares, a few people rustled in their seats, and the remainder diverted their eyes to their laps as if a sudden important message had appeared on their notepad. After a pregnant pause the answer came, "When someone is talking." A relieved, yet embarrassed, chuckle rippled through the suit-clad audience. The advice is a good start; however, listening entails significantly more effort.
The project was out of control. Within a two-week span, the project manager reported a slide of at least six months. To put the postponement in perspective, the original project plan was a total of nine months. Accusations came from everywhere. The customer complained about the project manager, requirements analysts were frustrated with the customer, the project manager was pushing on his leads to close requirements gathering, there was infighting within the team, and management did fnot know whom to believe. The organization was in mayhem and the only solution was to hire an external auditor to sort out the facts.
It happens hundreds of times a day around the world, the CIO calls an urgent IT Management Committee meeting. She has heard that one of the projects in the portfolio, a seemingly simple project doing a routine upgrade, is projecting a 20 percent cost overrun and will be three months late. How can a project go that far off track since the last week's executive team meeting? Managers scramble to get their stories straight, determine who to blame, form opinions and alibis, and pummel the project manager for failing to manage the project correctly, even though he has been saying the project is in trouble for months. The project has drifted from its initial intent and now the ultimate goal is to find someone to blame.
As mentioned last week, alignment is of the utmost importance. Achieving alignment, at first glance, is easier when the supplier works for the same company as the customer, say an IT organization delivering a new application to a business unit. However, from my experience there is little difference. In fact, exploring a vendor's world, where access to the customer is inhibited, sheds significant light on techniques to improve the customer-supplier relationship. Classically, vendors must wait for a request (RFP or RFQ) before they can get access to the customer. Exploring ways of "fishing up stream," as an eloquent account manager friend of mine says, is critical in improving project success. To understand this we need to review a couple of case studies on vendor success and failure.
I have always enjoyed cooking and rarely thought of it as a chore, let alone a project; however, when my wife became ill, I became the household chef and had to learn a new way to cook. Every evening was a project with varying degrees of success. Eventually making multi-course meals from scratch became easier. I used to joke that cooking Chinese food was two hours of chopping fresh vegetables and ten minutes with three blazing woks.
Risk is a risk in itself. It is risk for you if you dare bring it up. Have you ever identified the risk, in writing, that your boss' inherent inability to make decisions is going to sink the project? How about the company loss of market share will require laying off half the project team? Or, that the project manager has never had a successful project? These are CLMs (career limiting moves). Even mentioning such common risks as a company's inexperience in the project's domain is too risky to put in the risk register. It is as if management enjoys blissful ignorance and relishes the firefight that ensues. Cowboy mentality. Identifying risk, modeling mitigation plans, and compiling contingency are too boring compared to the thrill of disaster recovery.
Loyalty. I have heard a lot about loyalty lately. It focuses on a company's loyalty to their employees. The current stormy economic condition means layoffs and employees on both sides of the pink slip are unsettled. Albeit, conditions today bare a stronger semblance to a hurricane stalled over the employment sector, while Wall Street seems to be holding its own, when the floodwaters subside both employees and employers will be on more fertile ground. As opposed to straining loyalty to its breaking point, it is only taking on a new form.
Estimates are wrong if you cannot beat them half of the time; they are also wrong if you are not late half the time. Neither condition is one that should make management upset. In fact, matching that score is a great accomplishment. So how can people get so emotional about the statement? The answer is that people do not understand estimates and how they work. Through years of estimates being treated as quotes, we have been brainwashed into thinking our best effort is to meet the date, not better it. Heaven forbid if you are late. This lack of understanding is very evident by the number of blogs on the subject and some of their bewildering comments. The comments point out wildly different views. Some people think that Monte Carlo analysis gives you an estimate that has a 95% chance of being right and others believe that using Agile relieves people from having to make estimates entirely. Both of which are plainly not true.