Eight to Late

Sensemaking and Analytics for Organizations

A walk in the park

with 4 comments

 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.

Written by K

August 2, 2009 at 7:06 am

4 Responses

Subscribe to comments with RSS.

  1. Hi Kailash,
    You’ve connected the dots to a perfect T. “Walk in the Park” it was..Surprising that your client did not see the writing on the wall early enough.



    August 3, 2009 at 3:40 pm

  2. Prakash,

    Thanks for your comment. I think my client’s blindness – like the vendor’s – might have been caused (at least in part) by cognitive bias. I reckon these biases play an under-recognised role in many project mess-ups, particularly where human judgements are involved. I’ll be looking into this in some detail in a future post.





    August 3, 2009 at 10:30 pm

  3. Kailesh
    Just came across your blogs and this one struck a particular chord. Underestimating the complexity of a project is not just a problem for the client – the vendor also loses many times over:
    1. The extra time and resources expended means his profit goes out of the window
    2. He also loses the revenue opportunity of using those resources on other work
    3. The client isnt happy so there’s no reference case study for the website
    4. …And no on-sell from the client.

    I have found that using some simple models and tools, it is possible to get a reasonably accurate indication of the complexity of the project before it goes ahead by asking a few key questions.
    In one of your earlier blogs you reviewed an article by Maylor, Vidgen and Carver on complexity and they argue for a 5 dimension model. In fact, because complexity is exponential in nature, you only really need 3 factors to get a rough assessment of the scale of complexity – I use:
    No of Stakeholders x No of Processes affected x
    Time (in months)

    First ask the client where, on an exponential complexity scale, he thinks the project lies, then ask him to do the calculation. Typically the resulting number is much higher up on the scale than he anticipated. Because that gap represents quantifiable cost (skilled project/programme manager time, additional planning and communication etc), this approach allows you to get the client to nderstand the need for a more realistically scoped project plan.

    However, as your blog suggests, project complexity is only an issue if the organisation and its supplier don’t bring the required level of experience and capability to the table. My experience is that the problem usually starts with the client’s lack of understanding of the work involved to implement the changes, combined with the supplier’s poor due diligence in their enthusiasm to get the contract.

    So complexity needs to be seen in the context of the capability of the organisation to handle change: the capability / complexity gap.

    I deal with this in a book that is coming out in the autumn – if you are interested before then, the key models are at: http://www.inpactuk.net

    I’d be happy to pursue this further with you
    Keep up the good work!

    Peter Duschinsky
    The Imaginist Company


    Peter Duschinsky

    August 4, 2009 at 2:53 am

  4. Peter,

    Thanks for your very interesting comments.

    All too often project complexity is the “elephant in the room” – unseen by the customer, ignored by the vendor. Quantifying complexity using easy-to-understand variables is an excellent way to help folks on both sides get a feel for the magnitude of the project. The three variables you use to characterise complexity make good sense. Further, they take into account many of the factors used in Maylor-Vidgen-Carver model. I’ll have a closer look at the models on your web site when I get a chance.

    Thanks again for your comments and insights – I’m sure they will be of interest to some other readers too.





    August 4, 2009 at 10:15 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: