15.5 Negative Contributing Factors

< Day Day Up >

No project is perfect, no matter how hard you try. In my view, you look equally foolish taking credit for serendipity and dismissing poor results as the inevitable consequence of undeserved misfortune. The previous section presumed to reflect success against how well we did certain things, and how we would do them even better next time. In this section, I look at circumstances wherein you may find it appropriate to address the less heart-warming results that visit nearly any project of consequence.

Let me give this some perspective. I am a relatively accomplished cabinetmaker, and have received some generous compliments about my work. Not only is that somewhat embarrassing, but it takes me some time after I finish a project to stop obsessing over the mishaps and blemishes that can be found in all my work. Apparently, those who compliment the work do not see the imperfections that gnaw at my gut, or they appreciate the overall value in the work, and are thus gracious enough not to mention my faux pas.

Put another way, success is somewhat binary. Either you basically succeeded, or you did not. When you look for the downside in your project, and you should do so aggressively, do not confuse style with substance. Poor results are basically the degree to which your initiative had a negative impact on the business. Those who go crazy about how messy or difficult your project was either do not get it or are disinclined to give you the benefit of the doubt anyway. Because you cannot change that, make your case honestly without being defensive.

Having said that, go ahead and develop a list of project issues that require serious discussion from a lessons learned perspective. Look for things you could have done differently that would have:

Created more satisfied customers
Driven actual project costs back toward the budget
Achieved the dates and deliverables once touted as practical and desirable

15.5.1 Missed Dates

Included in Chapter 9 is a laundry list of date slippage opportunities you might want to review in support of this conversation. When you get into the scheduling postmortem, however, start by ascertaining what missed dates, if any, impacted scope. If Fred was 3 weeks late and that forced Mary to scramble to make her deliverable, which may be irrelevant today, unless it was more of a train wreck than an inconvenience. Even some customer, beneficiary, or sponsor angst over a missed date is regrettable but unimportant unless someone in the audience chooses to make it "Custer's Last Stand." There is a section in Chapter 7 (Section 12) titled "When Late Matters." From a lessons learned perspective, being late matters when:

A costly or unacceptable workaround is required. Examples include staff augmentation, temporary facilities, manual workarounds, and buying supplementary hardware or software to effect a workaround that cannot be recycled once their project usage is complete.
An expensive and embarrassing penalty fee from a landlord or government oversight body, for instance, is levied because you could not leave a building or print reports on schedule.
The beneficiaries' business as usual (BAU) process is severely interrupted for an unacceptable time span. That could be hours, days, weeks, or even months.

15.5.2 Missed Budget

Only a few avenues can be explored:

The original budget was too optimistic (i.e., insufficient).
A poor job was done comparing the final plan against the budget.
You did not keep a close enough eye on ongoing expenditures to contain profligacy or apply for relief well in advance of surprise expenditures. This area is especially vulnerable if you have an irresponsible subteam or vendor.
Previously unthinkable disasters actually happened and proved quite costly.

15.5.3 Missed Requirements

Two possibly fertile grounds can be plowed:

A requirement could not be delivered and this was not good. The most likely cause is a bad bet made on a solution. I recounted experience with this in the first two chapters with the Integrated Services Digital Network (ISDN) project. By "bad bet made on a solution," I mean that the wrong technology, implementation strategy, or resource was mistakenly applied. This does not necessarily imply neglect or malfeasance, although a manufacturer, team lead, or vendor might look good for the role as fall guy. My personal takeaway from the ISDN project was to question all assumptions, walk through the implementation strategy with a jaundiced eye, and validate the feasibility of the solution well in advance of a "go/no go" date by which you could take another direction, issue a jeopardy, or recommend scrapping the whole thing while it looks like, but has yet to become, a waste of time, money, or a career's good will.
A requirement is inadequately delivered. Among other things, this could mean that:
- Parts are missing.
- Performance is not optimized or haphazard.
- Beneficiaries do not take kindly to it.
- It is a beast to support.

These are all very common symptoms of the unfortunate project outcome. Many of the comments just made about missed requirements can apply to this scenario as well. You also have to investigate whether or not the proper amount of discipline was applied during the design, risk planning, build, and testing phases for that requirement. Early on, true professionals worry if a proposed solution will work. At some point that changes to worrying if it is showing signs of working. ^[1]

The word discipline was used to flag the need for constant surveillance. Assuming all will go well without enough eyes on the process and resources with a willingness to escalate the moment one senses things are not going well is an absolute responsibility of all stakeholders. This includes beneficiaries, once they are looped into the project. I am amazed all too frequently at people who sense impending disaster but turn away in disgust, helplessness, or apathy. Do not fall into that trap yourself, or the equally counterproductive trap of assuming that someone else is watching carefully. You are better off assuming that nobody is, unless you are.

Remember this too. In today's world, your real or apparent inattention can be construed as disinterest, which can deincentivize those less than professional types who can be found in any crowd. So inspect early, often, and with a little public posturing such that even the project laggards get the idea that "big brother" is watching.

15.5.4 Operational Handoff Miscues

I really struggled writing about this in Chapter 11, just as I wrestle on every project with the prospect of getting the legacy support teams to help bring the deliverables into BAU operations. I am admittedly quite strident and detailed with so many project management tasks, but on this topic I can only say that your best approach is to cozy up to the operations people and do practically whatever it takes to get them to adopt your project off-spring as their own. Understand that they can spend a lot of your energy in the hopes of avoiding as much of your project, and its output, as they can. Seriously, the issues here are predictable.

Did you fill out all the required documentation in a timely manner, review it with them, and get their sign-off?
Did you provide dollars for additional resource, training, or tools such that they felt comfortable adopting your project's deliverables?
Were you able to demonstrate to everyone's satisfaction that:
- The processes you deployed are stable in the legacy environment?
- A ritualized fault management process is feasible?
- Manufacturers, vendors, and internal groups will stand behind your deliverables to the degree that the legacy support teams can partner with them to resolve future glitches or outages after you vacate the premises?

Most project managers could write long essays on these questions. You may have to one day, also.

15.5.5 Ownership

Also known as "roles and responsibilities," this is a very likely opportunity for miscommunication and ensuing chaos. In large projects, it is not unusual to find unrequited ownership of deliverables spanning work groups. What tends to happen in this circumstance is that Joe and Marie, let us say, share a deliverable, but somehow do not fully coordinate the ownership and execution of every detail. This disconnect can be the result of factors that range from work or risk avoidance to someone, possibly you, simply dropping the ball in terms of accounting for everything. The implementation strategy walkthrough touted in Chapter 4 is the best way to identify and work through any gaps, in advance of implementation.

Should you identify this gap in your postmortem, do not be afraid to revisit it with the troops so that by the time your next project turns up everyone will be more educated, vigilant, and proactive regarding this potentially deadly challenge. I can cite many examples from my past on this one. The most recent instance had to do with the implementation, or lack thereof, of a telecom standard for electrical grounding of equipment racks for servers, routers, and switches. We specified this standard (TIA607) to the electrical and cabling consultants who did the detailed drawings and provided oversight of the electrical and cabling contractors who constructed these systems. There was a gray area, however, in which it was not clear which consultant and which contractor owned certain pieces of the grounding system in this huge facility.

In other words, although there was only one grounding system per se, it was divided between "base building" and "branch" systems. For whatever reason, the two consulting companies saw fit to mentor their pieces in the strictest of interpretations. The project team, myself included, failed to take responsibility for ensuring that the complete grounding system met spec, even though individual parties alleged that their parochial territories conformed to TIA607. It literally took months to complete the finger-pointing phase and subsequently enter and complete the problem resolution phase. We endured a lot of messy discussions to affect, at project's end, what we should have done at start up time. That was to identify:

Who would own the deliverable of TIA607?
Roles and responsibilities for components thereof
An escalation process for territorial disputes
Testing procedures
Remediation
Final certification

Pulling this together at the backside of the project was messy, if for no reason other than the sheer volume of players, which included the electrical and cable plant consultants, the project office, the two telecom team leads, facilities engineering, facilities management, the project architect, the general contractor, and the electrical and cabling contracting firms. Looking back, we are quite certain that had we driven the TI607 implementation ownership issue through the gauntlet 18 months earlier during the planning phase, we would have long since stopped gnashing our teeth.

On a personal note, this incident reminds me for the umpteenth time that I can never ask, "who owns this one?" too often, as annoying as it sounds.

15.5.6 Culture

As a consultant who changes environments every year or two, I am particularly attuned to the cultures of my clients. By this, I do not mean the kinds of things that human resources types speak about, such as diversity and empowerment, but the reality of how people interact. I spent my earlier IT years in the more congenial worlds of Dallas and Tampa, compared with the most recent decade slugging it out in Manhattan; however, do not think this is a regional conversation, because it is not. It is an observation regarding the different ways that corporate cultures are manifested in terms of cooperation, competition, problem solving, work ethic, civility, quality assurance, morale, and other institutional behavior. I have noted sometimes amazing disparities in:

How much public arguing is tolerated, versus backstage lobbying
Whether or not people show up to meetings on time (i.e., take them seriously)
Whether or not holding grudges and taking retribution are tolerated
How much real work, and positive results, are encouraged and rewarded
Whether or not unprofessional work or behavior is sanctioned

It is hard to give guidance in this area in terms of lessons learned because you do not want to get into a sociological analysis regarding poorly delivered requirements, but cultural dysfunction does impact project results. As with other negative contributing factors, be honest and fair about corporate culture, but use it more for tempering your remarks than as a bulls-eye.

^[1]Perhaps you could think of this as pre- and postnatal care.

< Day Day Up >