Project Governance
As I was driving to work this morning, I started thinking about some of the projects I had worked on the last couple of years. Some brilliant, some not so much, others mentally challenging and a couple just very basic. One thing that hit me, was how different the project delivery industry (e.g. IT) is to other industries.
I guess that is a fairly generic statement, but what got me thinking is how the IT industry seems to have a lot of grey area. Although consultants work on an hourly rate (for time and material projects) I still find that there are many clients that expect a lot of “free” work to be completed.
Baffling, I know.
I guess it has something to do with the fact that you can’t “touch” an IT solution. Sure you can touch software, but if you take a product and build a solution on top of it, how do you quantify what was delivered and how does EXCO determine that it has been completed.
This is the key question and leads into a biggy and something I’m very passionate about;
Project Governance
Clients will be clients, staff will be staff, but without proper project governance, your project is doomed to fail. In the project kick off meeting, everyone is buddy buddy and life is good, but the minute the vendor misses a deadline or an expectation is not met, hold on to your seat pockets, you’re in for a bumpy ride.
Project Governance is something that most companies adhere to in some shape way or form. Microsoft have also developed their “Sure Step” methodology to help vendors through the delivery process. Over and above that, you obviously have various other delivery methodologies that range between agile and waterfall plus everything in between.
Project Governance (yes this is a very broad term) is almost pointless when things go well, but essential when things start going a little south. It ensures that the client & vendor are able to have an objective discussion void of emotion by simply looking at the facts.
Good Project Governance
“Mr Customer, as per minutes dated 01/01/1900, we committed to doing XYZ. XYZ has now been changed, therefore we need to raise a change request which will effect the time frame and cost of the project.
Bad Project Governance
“Hi Pietie, I told you in our last meeting that you weren’t going to get those fancy drop downs. Now you’ve asked for them, that’s going to cost you a little bit extra mate.”
As noted above, project governance is a broad broad topic, but in summary, have a look at the examples above and ask yourself –
“Which conversation do I want to have with my customer?”
Great article! In addition to what you outlined above there is another tactic I have adopted in order to avoid the tit-for-tat, hourly pay vs. free work discussions. Starting during pre-sales and continuing through to the completion of the project I focus on the value of the project, rather than cost. By agreeing on how my consulting team and the client will create value for the company by working together as a team the who vibe of the project switches from cost (negative association) to value (positive association). This topic is too in-depth to fully explain here, so I recommend reading “Value Based Fees” by Alan Weiss: http://amzn.com/0470275847. Thanks!