Leadership

Before your project team high fives and runs for the hills, consider this

Most project teams finish a project and then flee with no looking back. Patrick Gray talks about why this is a terrible idea.

Human nature seems to have a dramatic impact on enterprise projects that are nearing their end. Usually, people buckle down for the final push, suspend interactions with family and friends, and devote their lives to making the project a success. When the sweat, stress, and long evenings finally abate, the project team disbands and runs for the next activity, like so many cockroaches scattering as the lights come on in the kitchen. Dramatic success or spectacular failure exacerbates this effect, with people wanting to leverage the success for a plum assignment or distance themselves from failure in the latter.

Rushing off to "the next big thing" after completing a project is a bad idea. In all but the most successful projects, there are items left undone -- good ideas that were shelved for the sake of time. Additionally, after a few weeks or months "in the wild," the people using the fruits of your labor may have some great (and often simple-to-implement) ideas for improvement. This community may also benefit dramatically from some refresher training that covers advanced topics and shortcuts that make the rollout of a new system and associated processes all the more effective. In each case, an additional return on the large investment of time and money already applied toward the project occurs, resulting in a multiple effect of sorts. In short, a small additional effort can have dramatic effects, accelerating and amplifying results. Before your team exchanges high fives and runs for the hills, consider the following:

Disposition and tackle the "greatest hits"

Remember all those meetings where you calmly assured stakeholders that you would complete various elements of the project "later"? While there are usually good reasons for delaying some elements, IT organizations lose an incredible amount of credibility when these "later" requirements disappear, never to be heard from again. Often there are gems in these lists that can be implemented quickly once the major elements of a system are in place, and they provide a great return on investment in increased efficiencies or compelling helpful functionality, not to mention enforcing the notion that IT makes good on its promises.

If you do nothing else, take the time to capture and consolidate all these requirements and put your best-guess timeframe on each requirement, even if that best guess is never. The mere act of assuring the community that their requirements have been acknowledged and dispositioned builds trust, and if you can assemble a few "greatest hits" that can be accomplished in the near term, all the better.

Conduct focus groups

Once a project hits the wilds of the user community, there are all manner of unforeseen elements that arise, from a business scenario no one envisioned, to creative shortcuts that users discover that could save their peers hours each day. Either formally or informally, visit some of the sites that were affected by your project 60-120 days after go-live, speak with those impacted by the project, and observe how they are using new systems and processes. You'll learn everything from how to improve the system in a future revision, to shortcuts that could save everyone time, to what the deployment team did or did not do during training and support. You'll also generate some goodwill for IT just by showing up, even while you learn how to make your systems and project deployment processes even better.

Do a six-month revisit

Many transformational IT projects, like an ERP or CRM rollout, spend significant time and money in the initial implementation laying a foundation for future growth. If you allow the project team, momentum, and leadership to scatter, never to return again, the hard work of building that complex foundation is for naught.

Generally, after six months the business community has experienced the foundational change enough to make intelligent comments about what to build atop the foundation and what additional areas to tackle. In the worst case, you'll do the hard work of laying the foundation, only to leave an empty site without any additional structure. By letting your user community have some time to adjust and then evaluating your plans for the future, you can make targeted, strategic additions to that foundation that leverage and accelerate the positive results of the initial project.

Everyone loves a successful IT project, but rarely do you achieve the best possible results when the project team scatters and leadership shifts its attentions immediately after go-live. After sweating through 95% of the work, apply a few more days and weeks of effort to identify quick hits that can generate big returns for only a few more percentage points of effort.

Patrick Gray is the founder and president of Prevoyance Group and author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. Prevoyance Group provides strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com, and you can follow his blog at www.itbswatch.com.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

3 comments
asa.ingerson
asa.ingerson

This advice applies to every project I've ever seen. Value add is enormous, and business stakeholders treasure PMs who show this sort of commitment to business outcomes.

tsnow
tsnow

Unfortunately, too many large organizations think that Project Management is ideal for contract work and, as an expensive "hired gun", the sooner they can get you out the door, the better. Most of these companies have not figured out that the PM walks away with all their knowledge and there is no one internally that can fill the gap, let alone deal with shelved ideas or issues found post-deployment.

RockerGeek!
RockerGeek!

I don't work on projects much bigger than re-imaging machines for clients, but even in that small scope I try to check up on them later. Generally I'm passing by their office on my way to/from a different person's desk and I peek in to see how they're doing. And I always ask if anything else is not working right when I'm working on any other issue. This has gotten me good rapport with clients. They like to know we're on the look-out for any additional problems.