15.4 Positive Contributing Factors

< Day Day Up >

There have to be reasons that explain the degree to which you and your team were successful, besides, of course, your brilliant leadership. Again, you are not nominating anyone for the Nobel Peace Prize but are putting into the record any techniques or approaches that others, including yourself, could benefit from applying, or avoiding, the next time they climb into the ring. Although some factors may be tricks of the trade specific to your project or a technology, and that is okay; what we are really looking for here is process. The following are areas you would like to be able to highlight as keys to your most recent success.

15.4.1 We Developed Excellent Requirements

The best projects do a great job of this. When this happens, implementation is much smoother and thus much more likely to succeed. This is because you know what you need to do well in advance of implementation time, and thus have the time for careful and thorough planning. The opposite of this, of course, is that you have to constantly make adjustments as you stumble across inconsistencies or gaps in previous assumptions or decisions. From the point a misstep is taken, getting back on track is a rough prospect, particularly given that it may take a while to realize you have wandered off the reservation. Mistakes, especially those early ones, tend to trickle down and compound the error rate as time passes.

Remember that the feasibility of implementing requirements should have been reviewed as early as possible. Clearly that analysis, or lack thereof, may require specific scrutiny now that you recognize how your handling of this process caused significant issues during the implementation or operational handoff phases of the project. Had I chosen to write a chapter titled "Famous Last Words," there would have been a section in it titled "Yeah, we can make that work!"

If that sounds familiar, perhaps now you can see how you did not effectively drive the requirements process, because you assumed those reassuring words from a team lead were based on competent preimplementation modeling or analysis. It is human nature to think optimistically and believe that any unanticipated or highly improbable problems can be dealt with when they arise. Information technology (IT) project history suggests otherwise.

Remember the idea of formulating success metrics in advance of implementation? From a lessons learned perspective, success metrics can be considered a significant piece of your requirements package. Had that been the case, not only can we say that the project produced Deliverable X, but that its performance characteristics were Y and Z, as desired. Consider analyzing the results of your project from this viewpoint, and reflect on how that approach really helped, or how helpful it should be the next time around.

15.4.2 We Got the Big Picture Early

Complex projects are just that. Components must work well together or not interfere with each other, depending on the nature of your project. From a practical standpoint, this means that you and your team understood:

What the parts should be
How they needed to fit together
What, if any, sequencing would be required to achieve the desired results

The implementation strategy approach described in Chapter 4 is, to my way of thinking, the only way to do this effectively. Did you gather key team members around and find a way to articulate how everything would come together?

Look back at that process and discuss whether those strategies worked as well as you would have liked or if you would significantly modify your original implementation strategies based on the genius of hindsight. Take care with this conversation if the project scope or deliverables underwent transformation as a result of unforeseeable political, environmental, resource, or budgetary events. Every project, no matter how well conceived, will undergo one or more periods of winging it, because they just do. I contend that a great deal of project management competency stems from aggressive but informed anticipation. This does not require the powers of a psychic so much as enough humility to allow past surprises to teach you new wisdom.

15.4.3 We Understood Our Starting Point

No sane project manager believes he or she has been handed a tabula rasa (i.e., that blank canvas upon which you can exercise total creative freedom). Your deliverables must map into so many legacy processes that it can be confounding. Applications deployed to the desktop can have issues with existing operating systems or browsers. Going beyond corporate standards to implement "best in class" networking or computing platforms can wreak havoc with security or operations. You are not always free to select a vendor or product simply on merit. Not if the "standards police" are doing their job, that is.

The true practicality of your design can be an extremely serious matter, particularly in projects where there is a high degree of change or risk associated with an aggressive interpretation of scope. The problem is, this dynamic is not always as obvious as these examples indicate. It may not turn up until you start testing your new toys in the environment, and lose half your hair before remembering that you are injecting new technology into an already kluged and somewhat unstable environment.

There can be a more concrete, business-like aspect to this as well. For example, in our large campus project, we did not read the lease that our real estate department signed with the landlord. As a result, we learned very late in the game that there were certain hard dates regarding permanent power and legal occupancy that were in direct conflict with our plans to:

Build power-hungry computer rooms in the facility
House dozens of technicians and engineers for development and testing long before the legal authorities would allow

Because we neglected to read the lease, we were unaware that no cable entry facilities were being provided by the landlord through which we could bring high speed fiber optic cabling onto the campus from nearby telecom points of presence (POPs). The impact of this lack of knowledge led to an initial and totally incorrect assumption that networking infrastructure design and planning needed start up in the computer rooms, not down at the street a few blocks away.

15.4.4 Risks Were Correctly Identified

It would be great to include in your lessons learned document these words:

We knew if the vendor did not turn the customized system over to us by July 5, then the system would not be able to go live for the quarter-end close in September. In recognition of this potential risk, we entered into a short-term agreement with a service bureau to process the data offline to our specifications so that the production output as mandated by Statute would not be compromised in the event that our vendor did not have the new system ready for testing by July 5.

The following words would have been a bit more horrifying to write:

We had no reason to suspect that the vendor was incapable of meeting our deadlines.

The other significant point to be examined regarding risk is how things went if you had to face the decision of pulling the trigger on one or more of your Plan Bs, especially if that contingency was radical or expensive in nature. Sometimes pride, or fear of political retribution, keeps us from making hard decisions that attack risk but simultaneously make us feel like we failed because we had to push the risk panic button. This can also be categorized as stubbornness, which even a project manager can have too much of.

Of course, you should review risk in a general way, including whether what you anticipated turned out to be not so terrible or if risk that now looks so obvious never crossed anyone's mind. During these postmortems, an honest assessment may well be "stuff happens," but again, the wise among us learn to be a little more diligent or dig a little deeper the next time we consider what dire consequences may await us.

15.4.5 The Budget Worked Out

If you have millions to spend, you probably have room to maneuver. In this section, I have mentioned two real world overruns that were very costly and posed significant, jeopardy-level risk. In both instances, we escaped public humiliation from a cost perspective because we saved compensating amounts in other ways. Some savings occurred because the items were finally revealed as fiduciary fluff and thus cancelled. Other creative ways were identified to reduce costs based on an enlightened, midcourse change in a few implementation strategies. Did you let your project be like the custom-built home that has to cut corners at the end because you splurged on a pool table and jukebox in the walnut paneled basement before the roof had been raised? Did you neglect to hoard funds for that costly risk mitigation such that you could not afford to roll out Plan B when you needed to, without having to go begging for more project dollars?

< Day Day Up >