It never fails--at the end of the project, a whole lot of problems start cropping up. Tracking these problems in the flurry of activities occurring at the end of a project can be difficult. How can you handle these appropriately?
The Big Chill
“Wise up, folks. We’re all alone out there,” observed Nick (played by actor William Hurt) in the movie The Big Chill. That line echoed through my mind recently as I listened to a story unfold over lunch. It would seem that something had happened while we were hard at work the past few years…
While information technology and project management have grown and matured together over the last three decades, some recent developments have led me to think that the relationship may be uneasily strained in some locales. Apparently, IT project management can be commoditized, marginalized and neutralized. Or can it?
With the steady industry shift away from custom code applications to more commercial software packages and services, IT project management practices are necessarily changing to adapt to the new conditions. Is this a glimpse into what the future holds?
I was talking with Jim, a colleague I used to work with. He was sharing with me his experience with implementing a pretty comprehensive (and expensive) commercial software package at his company. We’ll call the software Enterprise.
This vendor had a pretty solid reputation and extremely high customer satisfaction scores. Jim was assigned as his company’s internal IT manager at the start of the program. Once the program got underway, however, Jim got the feeling that he was more of a passenger on this ship than a member of the crew. The vendor had some very specific tasks they wanted Jim to perform in his IT role--and program planning wasn’t one of them. The first assignment Jim drew was to pick his team. “Not so fast!” he cried. Jim wanted to plan the work before deciding on resourcing options.
The Enterprise vendor implementation team promptly sent Jim a colorful template that specifically defined the 20 or so roles that his team would play on the implementation program. Each role had a list of typical skills needed. All Jim had to do was find the appropriate actors and actresses to fill each role. Jim found the appropriate team members--even though he still didn’t know what the script for this movie looked like.
Out With the Old
While the IT team was getting set, Enterprise finished staffing the other teams on the program with solid representation from the business areas (finance, accounting, supply chain, etc.). They also joined the program “cast” based upon criteria noted by the Enterprise directors. After the full team was assembled, they wasted no time in getting down to business and moving the program forward.
Enterprise didn’t use such things as program plans. Instead, specific tasks were grouped together on spreadsheets and were provided to each of the teams (including IT) at the start of each week. These “day-by-day” documents were little more than activity punch lists of what needed be done that week (finalizing a chart of accounts, list of suppliers, entering all of your vendors, install servers, etc.).
While it was nice to have the tasks provided to the teams, it was hard not knowing what was coming up down the road. At times, the experience seemed to have more in common with an episode of The Amazing Race than a large software program. Jim recalled, “It was like being told to travel from London to Rome, solve a puzzle, proceed to a hotel pit stop and await your next clue.”
The narrow windows of activities sometimes left Jim’s IT team scrambling because Enterprise only revealed hardware purchases when Enterprise wanted them to be made (according to best practice). This approach didn’t take into account the long procurement lead times that Jim’s company required before making purchases of this nature, which led to many infrastructure items needing to be expedited.
Gathering requirements? Not necessary. Enterprise had already provided a list of two server configurations to choose from (regular or heavy duty) and two vendors who sold the configurations as a package. Not much for Jim’s team to do there. Desktop impacts? Please see Enterprise Bulletin #78--it details what the workstations should have and what specs you will buy for new workstations going forward.
Everything appeared to be perfectly anticipated by the vendor. As far as project management, Jim felt like he was just ornamentation on the set…
The New Normal?
The end of the first month was a real eye opener according to Jim. “The entire program was suddenly geared around the Enterprise report card.” Obviously, implementing Enterprise isquite an investment for any company to make.
As part of the effort, Enterprise compiles a report card sent out each month to the CEO of the client’s company and all of their direct reports. The report card summarizes the progress made in the last four weeks and brings to the CEO’s attention any risks or areas where the team may be struggling. It’s also an interesting way to let the CEO know how well the internal team follows instructions.
As for “classical” project management, Jim thought his skills were largely frozen out in the cold. Any time he tried to fill in a management function that he felt was being overlooked, he was politely asked not to do that. I can certainly understand why Enterprise software might prefer an approach like this. They have probably been at the receiving end of too many client complaints about large IT programs blowing their budgets and succumbing to the quagmire of numerous delays. After all, program challenges are a very real concern on large IT programs.
I would also suspect that the Enterprise team has seen its application (and image) succumb to over-engineered (but well-intentioned) project plans and overenthusiastic architects planning five-nines and “high availability”. After getting burned once too often, Enterprise has taken the reigns of the script and moved IT and project managers to the back of the room where they can’t cause so much trouble.
What Worked Well
Within a few months, the report card proved to be a surprisingly valuable tool. It forced the program team to come to grips with what was going well and where they could use some help implementing Enterprise. It caused the whole company to become involved with the application investment instead of it being “something else that IT is doing”.
Compartmentalized task lists also kept project teams focused on what they were doing and kept teams from becoming overwhelmed at what still needed to get done. Instead of looking up at 110 floors in the stairwell, you saw it in two flight increments so it always seemed doable. The “cookie cutter” approach to the IT implementation did reduce a lot of the options and hand-wringing within IT about how best to solution the final product. That activity was taken off the table.
Where It Fell Short
Jim noted that this planning approach worked well for the things that needed to be done within the Enterprise ecosystem. But for things that needed to be coordinated with the environment outside of the Enterprise ecosystem, the approach fell short.
Dealing with legacy systems, interfaces and planning for how the Enterprise software would work with everything else in Jim’s legacy world is, by definition, specific to Jim’s company and can’t be scripted ahead of time. Here is where old-fashioned systems analysis and detailed planning couldn’t be avoided. While Jim did cut some of the PM corners in the space, his team did have to rely heavily on the basics and react to this work much later than they would’ve preferred.
All of these efforts somehow came together to deliver the finished product pretty close to the anticipated delivery date. It took a strong hand by Enterprise to control aspects of their product that they understood, and IT to figure out how to integrate it with everything else. The focus shifted from code and database calls to workflows and content and how to manage them.
The IT movie industry had to get used their role in a YouTube world.
Are we really all alone out there? I don’t think so. At least in the example from Enterprise, there are some techniques that clearly worked pretty well and a few that were inadequate.
What it really indicates to me is that project management and IT need to be able to adapt more quickly to a changing landscape and they need to be laser-focused on delivering measurable value. By constantly taking the broad view of the role IT plays and how it directly helps (or hurts) their customers, they can refine themselves for what may or may not be a trend in the future.
The time has clearly arrived for IT and project management to take a page from this script and understand what we can all learn from it. The business needs a result--not a long, complicated journey. If we are open to new ways of doing things, carefully tuning the process and improving our abilities to influence and collaborate with our business partners to achieve the best possible outcomes, then we are truly helping to create those win-win situations for our companies.
If we as IT feel that we are “all alone out there”, it will be no one else’s fault but our own.
Tom, great story and replies. I so agree with your bottow line advisements, "...project management and IT need to be able to adapt more quickly to a changing landscape and they need to be laser-focused on delivering measurable value." And yes, it is up to us..!
Sadly I've been involved in an "Enterprise" like enterprise and seen some of the damage that can be done as the outsourced provider clears the decks for their team to take over.
I've also seen this turn around to become an excellent partnership arrangement with the outsourced provider gradually disengaging as the organisations maturity grew - with mutual respect and longstanding friendships in place.
However it all came down to the personnel involved and their attitudes to the relationship and their willingness to work together.
This is a disturbing story. Based on years of experience, as client and as consultant, anyone who buys a large software implementation like "Enterprise" had better always remember that the vendor's definition of success almost certainly doesn't match that of the client. The implementation process the vendor proposes will be optimized for the vendor's convenience.
While it is perfectly appropriate to place a large amount of responsibility on the vendor's implementation manager, the client PM should make sure that (a) the scope of work in the contract covers everything the client wants, using measurable criteria of delivery, and (b) that the overall implementation plan includes actions by both the vendor (and any systems integrators or subcontractors) and the client in a coordinated manner.
Once you pay them, the vendor implementation team goes away, with another "success". The client has to live with the results.