Monthly Archive for April, 2009

Page 2 of 2

85% of IT projects fail. I know why.

Published on April 17, 2009 in Business, Career Development and Observations from the Web. 2 Comments Tags: , , , , .

We’re all being suckered here, and not just in IT. Why does every house ever built seem to go over budget and over time?

  1. People thinking they can be Project Managers;
  2. People not knowing the true cost of change;
  3. Not having enough money to get the job done.

These problems extend to IT quite easily.

If we think of all the IT projects that fail (or if we want to feel better, think of the 15% that are successful), we must examine what it means to fail:

  1. Over time.
  2. Over budget.
  3. Didn’t deliver what the customer wanted.

The first two can be stamped out with a good Project Manager. But the real problem is number three, not delivering what the customer wanted.

Sometimes this is accidental, and sometimes this is on purpose.

One example is RFQs. Companies make a bid on IT work using an RFQ. There are two methods a company can approach this:

  1. Include as much detail as possible, and create as detailed as possible quotes. This can take a lot of time, make you seem unresponsive to requests, and have quotes that far exceed competitors (more on this in a bit).
  2. Include as little as required to gain the RFC. Externalise costs to things outside the scope of the RFC. This means you can reply quickly in the RFC process, and have quotes that appear better value than competitors.

Now lets examine the outcomes:

  1. By having high quality Project Managers, a robust change control process (that captures the true cost of change), you have a project that can be delivered on time and on budget. Depending on how good the requirements gathering was at the start, and taking into account the shifting target of meeting customer requirements now (and in the future), you might have a successful project.
  2. Or by not exploring the true scope of the project, you can easily get overwhelmed in trying to deliver a solution using nothing by elbow grease and hard work. As costs rack up, these are presented to the customer as unforeseen costs that are not typical of a project, and hence are outside the RFQ and must be paid for separately. In the end morale slips, and you have a project that met some requirements at some point in time, using most of all of the budget and time available (if not more).

So why would anybody pick option two, when it leads to near certain failure?

Greed. When we were examining those RFQs in the beginning, we were seduced by the quotes given to us, without really thinking about the true total cost of ownership. And we couldn’t since we weren’t provided with the true cost of the project by the bidders. And they didn’t do that so they could get more business. And businesses don’t punish vendors as they just see IT projects as being inherently risky.

They’re not. We’re just being taken by a ride by all the people in the system, leading me to believe that this is a systematic flaw, not just a specific component.

To fix:

  1. Businesses need to better understand their requirements. Seriously. Seriously. I’m not kidding. Gather the requirements for now. Gather the requirements for the future. Think of all the possibilities for the process. Is everything covered?
  2. As requirements change throughout the project, scope the change, go through a formal change control process (not just lip service either), cost the change in terms of resources and time, take the value of the benefits to the business and ask, is it worth risking all this (the risk you’ve calculated, and the cost) for the change to meet the requirement?
  3. Push your vendors for accurate quotes. Maybe this needs to be enforced through contracts. Sure, you didn’t foresee that the SCSI drivers were only for Windows not Linux. Sorry, that’s not a valid reason to not include the cost of having an alternative driver solution.

Finally, lets not accept that IT projects should fail. They should never fail. Never fail 85% of the time, never fail 0% of the time. I refuse to accept that projects should fail in this manner, and if they’re always failing, then we’re doing something wrong.

End-to-end Identity Management with open source?

Published on April 5, 2009 in Business and Identity Management. Closed Tags: , , , , , .

After working with a relatively large identity and access management implementation over the last year, I’m really interested to continue working in this field.

There are with large projects many lessons learned, and plenty of times when you think to yourself “could I have done this better?”

And so, I’m contemplating getting into the Identity Management business.

But before I do, there seems to be a few different paths to take:

Each of decisions has their own pros and cons, so lets explore those.

First, supporting Oracle. Big organisations need heavy identity solutions. They have many different providers of identity data, and many different services that consume that data. While the organisation owns that identity data, they don’t have much control over where that data is stored and consumed. Hence the need for lots of different agents to interact between identity provider <> identity consumer. And that’s all well and good, but the competition for providing support in this space is fairly niche. You must be big enough to support the product, and to find customers big enough to want the product. In New Zealand, this is a fairly limited market, and is owned, unsurprisingly, by Oracle.

Next, there’s supporting the Sun identity stack. I have lots of experience on the Sun identity stack, and it has its benefits and pitfalls. The main difference between the Sun stack and the Oracle stack is open is open source (Sun) and one is not (Oracle). For customers this means not paying Sun for the software, but to implement something so significantly complex, you really must have a smart consulting company on your side, like Sun. The same arguements about being heavyweight apply here too. Only certain large organisations need this highly complex solution.

Next there’s the middleweight solution, Triplesec. Triplesec provides a lot of the functionality of the heavyweight solutions, but underpinned on relatively less complex architecture. The pitfall I’m finding with Triplesec is a lack of documentation. One advantage (or disadvantage) of the heavyweight solutions is documentation, lots and relatively thorough. Triplesec technologically is sound, but without documentation or support, you’d have to have a lot of trust in your vendor to be implementing this at the moment. Also to my knowledge, this solution is relatively untested – I haven’t heard of any large scale implementations. Not that this should stop you, but just be warned that you’re on your own here.

Finally, there’s SimpleSAMLphp. This isn’t a whole identity management solution as provided by Oracle or Sun, but more a way to take information from an Identity Source like an LDAP directory, and then authenticate against that. Provisioning new users and managing multiple disparate identity sources into one meta-identity provider this is not, but for a simple identity solution that is relatively easy to understand, support, and is widely in use (throughout all of Norway and Denmark), pretty bespoke, and using open standards. A good solution for the majority of small New Zealand companies.

And for some fun, I’ve been working on a logo for this project:

Identity Systems