blogs.conchango.com

welcome to the conchango blogging site
Welcome to blogs.conchango.com Sign in | Join | Help
in Search

The enthusiastic skeptic

Conchango are busy and need talented consultants in and around London. Interested? Email me or send me a message

Project needs versus blame

Hi

 

It's been a while since my last post and this has been sitting on my laptop for months.

 

One of the things which has troubled me in my life as a consultant is the “Project activity – needs versus blame” conundrum.

 

Let me describe in a bit more detail what I am trying to get at.

 

Example

We are working a project to build a new datawarehouse. We need to get a load of data from a bunch of different legacy systems and to do this we need our client to provide us with the schemas for these systems and information on what it all means so we can do a data mapping exercise before we build our new DWH schema and ETL jobs.

However due to our client being under-resourced the nominated person doesn’t have time to do this for us. As a result one of our consultants steps in to do the work. He then, because he is not able to get enough time with the experts, makes a number of errors which we find out in UAT. Costly rework ensues pushing the delivery date back, makes us look like mugs and causes us to lose money by going over budget.

 

So what do we do about it?

As consultants we have a general reputation (deserved or not!) of being all-knowing, all-seeing and can-do it all.  I know some people probably disagree with that statement but I think the implicit deal that many of our clients buy into is that if they pay us a lot of money we will take their problems away from them and return back to them beautiful solutions.  And most consultants out there really do want this.

 

We generally are very focused on delivering things because we have to! That’s what we are paid and judged on.

 

So the problem we have here is a task that our client really needs to do for us remains undone. The PM (and the rest of the team) is in a catch 22. Do we stop work (effectively) and point the finger at our client?  Or do we do the work ourselves at the risk of getting it wrong, taking too long, doing something that we don’t have the time for?

 

It’s a very difficult discussion to have to try to justify yourself to a client when they see a poor quality delivery AND have to pay more money for it. 

 

I think often that many clients do not really understand what developing a new software decision will mean for them in their day to day work.  To get it right requires a huge amount of involvement from them which will mean often that they struggle to do their day jobs.

 

So how can consultants get around this problem?  It’s really not easy and requires a fair bit of courage and honesty on the part of you and your client. 

I think the key is communication. This is something that Agile stresses but I don’t think it's limited to just Agile. I think it’s important to any consultant and project whether its waterfall, agile or something else.

 

It needs to start at project inception and both sides need to agree on what is going to be required from the other to complete the work, write it down and refer to it through the course of the project.  At this point we should be saying to our clients that if either party feels that the other is not holding up their side of the bargain then it should be raised immediately.

 

Next thing is to keep talking through the course of the project, make sure that the client is aware of what’s happening all the time and doesn’t get surprised.  This can be with email or just a quick chat by the coffee machine.  If they are too busy to see you as much as you’d like then send them an email…they just might read it.

 

Another thing to do is to try to ensure that you have a good relationship with other senior stakeholders as we all want to avoid single points of failure!  On any project but especially large ones we, as project managers, need to set up a strong governance structure so we can raise problems in a controlled environment.  And just on the covering your bases we should be conscious that we are always in a sale process.  Keeping the bigger picture of another phase can help us the see a bit more clearly what we should be doing at any one time.

 

It really boils down to agreeing just what the responsibilities are, make sure you agree to this upfront and if it needs to change then make sure we get this written down. When you write this down make sure the risks of this change are documented as well.

 

So if we do the work and make a mistake or take too long we can turn to our client in the spirit of honesty and partnership and have a proper, grown up conversation instead of getting a battering from our client and our own management.

 

 

 

 

 

Published 22 April 2008 16:34 by peter.murphy
Filed under:

Comments

 

Dumb Terminal said:

If you've read one of my previous posts about Fuzzy Logic , then you'll know that I was thinking about

July 29, 2008 16:46
Anonymous comments are disabled

About peter.murphy

Scrummaster, PM and general dogsbody on the Retail team at Conchango. I've worked for lots of different companies in lots of different fields. Topics of particular interest to me include Web 2.0, Agile testing, Agile vs UCD, raucous rock n roll bands and countries with better climates than England.
Powered by Community Server (Personal Edition), by Telligent Systems