John Mackay

I read an article today over at People10 titled: How Agile solves traditional pitfalls of IT Outsourcing and it got me thinking. To me that’s the sign of a good blog article; does it get you thinking?

I think the primary issue whether experienced via insourcing or outsourcing arises from a failure to consult, understand and manage competing stakeholder expectations rather than what development framework was chosen. To me a failure in this area can have project killing knock-on effects, limiting accurate and valid requirements which has the knock on affect of scope pressure or requirements creep which in turn pushes out timelines which invariably impacts budget--like falling dominoes. According to analyst Lars Mieritz review of recent Gartner research these knock on affects contribute to around 75% of all IT project failures.

“The fault, dear Brutus, is not in our stars, But in ourselves…”

Sometimes, both process and communication gets hijacked due to operational priorities, resource availability, organisational culture, external contractor priorities etc. basically a whole range and or combination of reasons. For instance if the business case has been ill-defined then whatever is designed may function perfectly but may fail to deliver the expected ROI. If the functional analysis does not go to transaction level then this can lead to the functional spec being ill-defined. If the requirements specification fails to explicitly outline in functional terms (read: tables, table fields, screens and logical processing) then what comes out the other end whether under a traditional Waterfall method or Agile method may also not match stakeholder expectations.

This is why so many companies now insist on their Project Managers using Prince2 as their large scale project framework because it involves a very strictly defined process or path which must ALWAYS be followed--otherwise you’re not using Prince2. As opposed to PMBOK which is more flexible in it’s methodology and maps better to Agile development.

So to that extent following the process of development--to the letter is all about ensuring good lines of communication all the way from staff engaged at the transaction processing level, respective business units, management and development teams--it’s all about good communication and more importantly open communication. We follow the process then so we can limit gaps in expectations i.e. developer expectations in terms of development overhead and maintenance, management expectations in terms of ROI and reporting and staff expectations about functioning and usability. So, a failure to maintain open communication amongst all the stakeholders and to follow the process adds significant risk to the project’s level of success, timelines, costs etc. and in the worst case scenario leads to a failure of the project.

Communication then is at the root of all project success or failure.

But getting a handle on communications means understanding the communications environment, stakeholder needs and expectations.

In traditional command and control management environments, management’s competitive advantage lies in being knowledge gatekeepers and communication controllers which in and of itself tends to introduce weak links into the communication chain not to mention plausible deniability for when things go bad which with IT projects they invariably do to some extent.

Managing staff expectations, fears and uncertainty are also key as you transition them from the status quo to learning a new way of doing things as well as reduced or even additional workload or responsibilities. Some of them may fear losing their jobs at the project’s completion and controlling the haemorrhage of staff departures prior to and during transition periods can add significantly to operational overheads.

Understanding that external contractor objectives are primarily about getting the contract and locking the customer in after all that’s where the money is and they have their own team to look after. That’s why their account teams invariably target executive management for the sale because they are the power brokers and decision makers and let’s face it they’re easier to sell to than IT who tend to ask a whole lot of pointy questions that are more likely to test the veracity of the potential outsourcer’s timeline, budget, technology and methodology claims.

…more to come in Part II