Keys to Project Success - Part 2

This post is a continuation of  Keys to Project Success - Part 1

Divide and Conquer

A number of years ago, a company for which I was working acquired a competitor.  The competitor’s business had to be folded into my company’s operations quickly to stem drastically declining revenue.  A very major portion of that folding had to take place in one of the systems for which I was accountable.  Partnering closely with my colleagues on the operations side of the business, we did a solid analysis of what needed to be done, and what the end should look like,  and then determined how much work we reckoned there was to achieve it all.  The work was substantial!  And, we were coming into our industry’s busy season in a mere two months.  The president of the company wanted it all done before we hit that season.

I recall looking at my prime operations-side colleague after working through a high level plan and schedule, which clearly demonstrated that there was absolutely no way we’d make a pre-busy-season deadline to have the whole thing done, and gulping!

“Well, just hire contractors and get it done,” she suggested.

“Won’t work,” I replied.  “They’d never come up to speed in time.  Doing that will actually add more risk to the project.”

No one wants to go to the CEO and tell him that he can’t have what he needs to cut loses.  Granted, the timing of the acquisition wasn’t ideal from a systems integration standpoint, but then timing often isn’t ideal.  So what were we to do?

So I looked back down at the various facets of the project – feature sets, data conversion, etc. – and asked my colleague, “So tell me, what has to be there day-one?”

“What do you mean?” she asked.  “Everything!”

“Well, not everything, I’m betting,” I responded.  “For example, if we go live mid-month, we don’t need month-end reports, do we?  Not on day one.”

“Well, no, but we’ll need them two weeks later!”

“Granted,” I continued.  “And the quarterly reports… they’re not needed until the end of the quarter, right?”

“Sure,” she conceded.  “But so what?”

“So what if we go through this list again, and be really brutal in putting things into some ‘need day-one’, ‘need end-of-month’, ‘need end-of-quarter’, and ‘need at the half-year’ buckets, and then see what the ‘need day-one’ bucket looks like, and rework this schedule to see when the ‘need day-one’ stuff can realistically be done?”

And so that’s what we did.  We broke the project into those phases, being very strict about what absolutely had to be there, and what could wait.  We also divided each phase into subprojects, which would have dedicated teams for each, each with its own project manager.  We included a project control office specifically for this project that would report directly to me, to gather overall project progress metrics, assist the individual project managers in tracking their plans, consolidating all that information, ensure effective and timely reporting, and ensure that I would know constantly where everything stood. 

As the one who’d been charged with overall project accountability, it was my job to go back to our CEO, and get him to buy into the new approach.  It was one of those times when I was glad that I had already had some good successes with the company and had established some credibility, and that I had my colleague on the operations side (who had been with the company much longer than I and had excellent credibility) beside me and backing me up!  We took the CEO through why an all-at-once approach wouldn't meet the timelines and would put the business at substantial risk, and then through are divide-and conquer plan, that would deliver needed features to run the integrated business only two weeks into the busy season, with other features following on in a ‘just-in-time’ fashion.  While he wasn't thrilled with what he perceived as a delayed delivery, he got it, and gave us the go-ahead.

And it worked!  The first phase was completed, and when the proverbial switch flipped, no one even noticed!  Everything worked, and it was as if the businesses had always been integrated and worked that way.  And the following phases were complete just as successfully.

I have yet to see in my career a project of anything but small size go well with a ‘big bang’ / all-at-once approach to delivery and implementation.  But I have had consistent success with dividing projects into phases and subprojects, and making sure each is properly managed as its own project in its own right, whilst maintaining the oversight needed to insure successful integration of each of the parts.


Read Part 3!

Add new comment