Wednesday, October 13, 2010

Why DO projects fail?

I don't want this post to degenerate into a mindless, multi part rant as if I have all the answers as to why projects fail. However I felt that at least one post one the most common cause of project failure that I have witnessed is most undoubtedly worthy of such a mention.

Strategic alignment. 

Well - duh, I'm sure most infosec guns out there would say. But what does that mean exactly? I had to conjure up a bit of a buzz phrase to encompass all the instances of which I've seen lead to project failure. So let's break that phrase down.


I'll give you a hypothetical example:
You are a security lead in a program of work. By program, I mean overarching stream consisting of multiple projects.
For simplicity's sake, lets assume it is a business transformation program where multiple core business objectives are expected to be achieved which will ultimately revolutionise the way that a business performs and conducts itself.

Now of those multiple projects, lets assume each one has its own PM. Then its own IT architect. It's own security consultant. It's own business analyst, developers, sysadmins, and so on and so on. Now lets's all assume they each look at their own project in terms of its overall objectives and work. Each project is meant to provide deliverables that fit into a cohesive whole (i.e. the program, as opposed to the project).

Still with me so far? Ok.

For a moment, let us further assume that each project meets its deliverables and timeframes within budget (ok stop laughing - we're pretending ok? so go along). Unfortunately, there is one limitation.

NONE OF THE PROJECT TEAMS CAN SHARE THEIR WORK WITH THE OTHERS.

What is the overall impact towards the program?

By assuming you're the program security lead, we'll further assume you have visibility of everything.

Now lets say you see that the program hasn't correctly co-ordinated all the work between project streams, and also further assuming that the program isn't going to invoke the Hand of God and didrectly meddle with each individual project when there is a problem, chances are that there will be a high cause of failure.

If each project is providing a deliverable that has no visibility of the end game or 'desired target' that is the commonality that all the individual project streams are supposed to be working towards, then nobody knows where they are going. Projects provide their deliverables in a vacuum. The net result is you will have a very unsatisfied business sponsor who is in all likelihood, going to ask the program manager to commit seppuku.

Infact, one of the sources I investigated as I was writing this stated the following:

"A project is considered a failure…whenever a project does not meet the expectations of the stakeholders."

This is a rather apt description I would say.

There are a raft of causes and reasons that projects fail. Many which you could argue aren't attributable to the above. However, if I was to pick the one cause of failure I see, it keeps coming back to a lack of strategy.

Some examples:
  • Point in time technologies selected to resolve an immediate problem with no alignment to strategy or architecture.
  • A program's risk registers not aligning to organisational risk registers.
  • Program leads disallowing information sharing between project streams.
  • Program leads not performing proper alignment of project deliverables to ensure a program's target strategic outcomes. 
  • Ensuring the program has clearly defined outcomes from the onset (outcomes which are specific, measurable, achievable, realistic, timely - that is to say SMART)
  • Maintaining clear (and consistent!) lines of communication breakdowns between project -> program -> business sponsor.  
 I could go on and on, but I'd probably start to bore you.

The fact is that there is a raft of material out there which highlights the common causes of project failure, and the reality is we learn more from our failures than we do our succeses. Given IT projects in particular have an aburdly high failure rate , there is a plethora of information available for anyone to draw upon.

I actually find this stuff interesting reading. If you read this stuff, I can almost assure you that you will be better equipped to recognise the symptoms long before the average PM does.

As a security professional, your efforts can only be improved by recognising the common symptoms and causes. Try to understand the business and outcomes which are both tactical and strategic. Try to ensure an alignment with both and get your business stakeholder engaged and supporting your efforts. Once you do this, funding discussions also come a lot easier. If you can do this, you will almost assuredly find allies - for example, the architect on your side as well, who undoubtedly also grapples with strategic vs tactical battles daily.

- J.

Tuesday, October 12, 2010

I am presenting at AISA Melbourne this Thursday

Gidday

For anyone interested, I am presenting at AISA Melbourne this Thursday for anyone interested. To be fair, it is largely content that we have presented previously for DD customers who had the privilege of seing this first. While it has been a few months on now, based on our experiences with the local market, I think the lessons are still rather poignant.

My objective is for anyone who is attending to get an idea of what was discussed at Black Hat and Defcon from a 1,000 ft view and hopefully get you all thinking in the right track of what sort of mitigations, controls and overall strategies to help you prepare for the next 12 months.

Details of the talk can be found here.

I hope you can make it. But if you can't or aren't interested, I hope you get to sleep in at least. :D


Cheers

- Jarrod