Eight to Late

 Sydney has a  wealth of bushwalking trails within the metropolitan area. Over the last month or so, a friend and I have been exploring trails in and around Lane Cove National Park, a reserve within touching distance of the city centre. Last weekend, we revisited a walk we had done a few weeks ago – a small section of the Great North Walk, which runs all the way from Sydney to Newcastle. The section we covered extends between the northern Sydney suburbs of Chatswood and Thornleigh (~14 kms in all). The first time we did the walk, it took us a little over two hours;  last weekend it took about three. The same trail, the same people and similar conditions (both days were sunny with a temperature of 18-20 C) – yet, the second time around, it took us nearly 50% longer than it did before.

Why the difference?

The answer is simple: although the weather conditions were similar during both walks, there had been about a week of rain prior to the second one. Consequently the trails were slushy and slippery, and we had to tone down our usual brisk pace. Along the way I slipped and fell,  which slowed us down even further.  So, although the two walks covered the same route in similar ambient conditions, one took much longer than the other  owing to the difference in  conditions on the ground and consequent events.  Reword this just a bit and you have a nice analogy with packaged software implementation projects: two projects following the same plan in similar environments; one taking much longer than the other owing to different conditions on the ground and consequences thereof.

Unfortunately, I reckon bushwalkers understand and appreciate the importance of ground conditions  better than many project managers.

Here’s a story from some time ago…

A company I consulted for was looking for an application to manage customer data (a CRM system by another name). After a complicated but thorough evaluation process they settled on a particular vendor, whose name is not important.  One of the reasons for the choice was that the selected vendor had a lot of experience in the industry that my client was in. Having done several implementations the vendor knew the ins, outs and all the possible complications of implementing CRM systems in this industry.

Since cost was a big concern, my client decided to go for a “near vanilla” implementation; one which involved minimal customisation of the base package offered by the vendor. This decision delighted the vendor, “That’s a good move,” said the account manager, “We’ll be able to offer you excellent terms as we know exactly what’s involved in this. We’ve done many vanilla implementations for similar sized companies in this industry.” My client was offered an attractive fixed price contract. Accompanying the contract was a high level scoping document which outlined the software and services that would be provided. I pointed out that the document didn’t provide enough detail on what the vendor would actually do. More importantly, it did not define which customisations were in scope and which weren’t. However, at a superficial level it appeared to address all my client’s concerns. Against my advice, the document was signed.

The vendor’s project manager was very experienced. He’d done a similar project (for a similar sized company in the same industry) a year ago. “We’ve done so many of these,” he said, “It will be a walk in the park”. He inspired confidence, as good project managers do. He had drawn up a  plans and schedules, accompanied by impressive Gantt charts and all sorts of project management paraphernalia. That’s not to say he didn’t consult us – he did ask for input on the tasks we were responsible for (data migration was one). This was provided to him. However, we had no idea about the duration of implementation-related tasks, so these were left entirely to him. These, he assured us, were drawn up on the basis of the scoping document which, in turn was based on that successful “walk in the park” from last year.

Owing to “conditions on the ground”  the project started falling behind almost immediately. To begin with, requirements gathering took double the allotted time  because the initial scope (which was as plain as vanilla) excluded required functionality that wasn’t available  out of the box.  Most of this was  easy enough to implement, and the vendor undertook to include it at no additional cost.  However, as I’d expected,  the analysis also revealed a handful of requirements that would be tricky to implement.  The vendor – quite naturally – deemed these out of scope,  and insisted that they would have to be charged separately.  Much haggling followed and a compromise was struck,  but it was one which left no one happy – the vendor got less than they wanted and my client paid more than they thought appropriate. It was the beginning of an extended and messy detour in the park.

I won’t go into any of the details except to mention than the project took about 50% longer and cost about 50% more than originally projected. The vendor’s experience in traversing similar terrain in similar conditions had lead to undue optimism, as reflected in the statement  that it would be a “walk in the park”.   Every bushwalk is a unique one – even those on familiar trails may hold surprises. So it is with projects. As the PMBOK definition tells us, “a project is a temporary endeavour undertaken to create a unique product, service or result”. Packaged application vendors and their customers would do well to remember this.