Cyber Security Predictions for 2017

2016 was a big year in the annals of Cyber Security, and 2017 promises to eclipse it.

Creating an Enterprise Data Strategy

An introduction to the process of developing comprehensive strategies for enterprise data manangement and exploitation.

A Framework for Evolutionary Artificial Thought

Let’s start at the beginning – what does this or any such “Framework” buy us?

The Innovation Dilemma

What things actually promote or discourage innovation? We'll examine a few in this post...

Digitial Transformation, Defined

Digitial Transformation is a hot topic in IT and big money maker for consultants - but what does it really mean?.

Monday, September 23, 2013

You Know You've been in IT too Long When...

Nothing says we can't be innovative and humorous...

This is an Android we can believe in...

  • You use a magic Quadrant to comparison shop.
  • You refer to the wait staff as customer responsive service interfaces.
  • You don't understand any longer how a Cloud could produce rain. 
  • You're confused between Socialism and Social networks.
  • You wish you were working on the Skynet project.
  • You refer to your kids as 2.0, 3.0 and talk about your family as the long-term release strategy.
  • You don't think Cheetah's are Agile because they don't sprint all the time.
  • You refer to politics as "run-time governance."
  • You watch reruns of the Matrix and still think it's cutting edge (the sequels don't count).
  • You're seriously contemplating creating a cyborg using a 3D printer.
  • You can relate to Watson on a personal level.
  • You're waiting for the local haunted house to add the solution release triage room.
  • You are beginning to think Larry Ellison makes sense.
  • You remember the good ole days when an Android looked like Yul Brnner.
  • You code comment your Christmas cards.
  • All your friends are now recruiters.
  • You count calories in megabytes. 
  • You'd like to outsource your relatives (just for a little while). 
  • Your idea of a romantic line is "stroke my touchscreen."
  • You'd like to vote for the Program Manager and Chief in the next election but are confused why the office is not on the ballot.
  • You start referring to talking as wireless communication.
  • You still think the 1996 Mac guy versus PC guy ad is cool.
  • You determine what to cook for dinner using an analysis of alternatives.
  • You think Strings are composed of letters instead of twine.
  • You are beginning to realize that life is merely a digital experience.
  • You remember Big Data being 64k.


Copyright 2013, Stephen Lahanas

Sunday, September 22, 2013

Top 5 Reasons IT Projects Fail

Last Fall, I wrote an article for Dice.com about the top 5 reasons ERP projects fail: that was in response to news of a specific project shutdown. However, the topic as to why IT projects in general seem to be so failure prone is worth exploring as well.

As far as hard statistics as to how many IT projects succeed or fail; it's difficult to get a clear picture. Part of the reason this is the case is that often when a project is clearly going to fail it gets "redefined" rather than cancelled. That redefinition represents a re-baselining effort that dramatically scales back expectations with the hopes that the reduced scope can be met. Sometimes that works, other times re-baselined projects are later cancelled anyway. If our measure for success was the original set of expectations associated with a project, the likely rate of IT failure would be extremely high - perhaps in excess of 50% of all IT projects.

In IT, building bridges to nowhere is fairly common, but no less costly...
This is a rather incredible statement of course, especially if we compare IT with most other types of projects across industries. What exactly does this level of failure really indicate though? It could represent any or all of the following factors:

  • That the expectations of the stakeholders were out of touch with the reality of what their IT provider organizations could manage.
  • The level of complexity was not properly gauged or managed.
  • IT is changing so fast now that a project defined last year might require major changes if it is still 'in motion' this year. 
  • The project was driven more by the perception of some need than the reality of a need. This of course refers to all those projects that are spun up in response to industry hype without a clear set of requirements. 
  • The technology assumptions (driven from the expectations) were hastily made and then never challenged later (or perhaps more appropriately - no challenge was permitted). 

While these five factors might be taken as the reasons that so many IT projects fail, they are in fact only the backdrop for the real reasons. Our focus needs to be directed to the fifth bullet point above - assumptions. Thus the five reasons we're focusing on here are related to why failure occurs after a project has been launched.

Even if a project wasn't launched under the best of circumstances, it still has a chance of succeeding if it is flexible enough. But what makes a project flexible? Is it the application of some Agile methodology or some other unique lifecycle management approach? Maybe not. Let's look at the real top five reasons that IT projects fail once they've begun:

  1. An inability to examine or challenge assumptions.
  2. A "silo" mentality.
  3. The inability to compromise.
  4. Technology-centric rather than capability centric perspective.
  5. Poor role definition and lack of project dynamics.

Let's look at these a little closer now...

1 - As noted previously, the inability or unwillingness to challenge assumptions is a huge issue on many projects. This is a problem precisely because of the manner that many projects get spun up (the factors listed previously). This is a little different than the traditional dialog on 'requirements' that's heard when explaining Agile methodology because in that conversation the focus is on the detailed design. Here the focus is on the big picture assumptions which in truth are much harder to face or deal with.  In any project, there are perhaps less than 10 issues which will determine the success or failure of the effort. You may have another 10,000 detailed issues or requirements in a backlog and each of those may be dealt with successfully yet still not save the project from failure if the core issues aren't addressed. Those core 10 or so issues are almost always associated with the initial assumptions connected to the project.

Those types of issues include things like the original intent of the solution, preliminary technology choices and solution architecture decisions as well as organizational approaches. There is no one correct mix of all these types decisions that ensures a successful project and that's precisely why those decisions should be reexamined on a regular basis. In other words, we shouldn't view the first hectic weeks or months of a larger initiative as infallible exercises in perfect thought or planning, but for some reason, many people do.

2 - The Silo Mentality. This refers to projects that become over-compartmentalized; where each sub-unit views itself more or less divorced or separate from every other. While everyone on a project needs to understand their roles (point 5) by the same token they must also all share responsibility for the outcome. There is nothing sadder and less justified than internal finger-pointing when failure occurs. This is a problem that is easily corrected with the right leadership and project structure. Whenever you begin hearing various players within a large project stating that issues relating to them are someone else's concern or responsibility then you know the project has developed this problem.

3 - The Inability to Compromise - We talked about this in a previous post from the perspective of team leadership; here compromise has an even broader context. Compromise here represents compromise between teams, by leaders - as well as compromise on large, tough issues. Lack of compromise is one of the chief symptoms of an 'inflexible' project. People will always have excuses and cite deadlines yet invariably where compromise fails to occur, deadlines are shot anyway and often the entire project ends up being cancelled.

4 - Technology-Centric Projects - This may sound funny coming from an IT geek however it is nonetheless valid. Let's look at Big Data as an example. What exactly does that new technology category mean to a business that wishes to jump onto the hype bandwagon? Does it imply faster data systems, better storage management or is it tied to specific Use Cases associated with that organization? If the expectations end up looking just like a Gartner article on who's doing what instead of Use Cases that illustrate how it can be exploited in your organization then you might say you've got a technology-centric project. The fact that you think everyone else is doing something shouldn't drive your decisions. If you've been stuck with a hype driven project then use the initial period to re-tune it to ensure that its aligned to your business. If you find that it's not then have the courage to reverse course if necessary (the earlier, the better - you can always come back to it later).

5 - Poor Role Definition and Project Dynamics - How you build the project is usually just as important as the underlying assumptions behind it. Understanding roles and how those roles and groups ought to work with one another is important. For example, an architect and a tech lead are two very different roles - one owns the technology the other designs the solution (completely different perspectives). Yet many organizations regularly confuse those two roles. Also, there's often not clarity in regards to who has oversight or leadership across groups. This last point relates 'project dynamics.' A flexible project still needs leadership - but leaders who act as facilitators rather than strict commanders. And the folks they lead need to be able to form working groups that have clear purposes and escalation paths to ensure corrective action can occur when needed (and not just on the little issues).

There are of course other factors involved in the failure of complex IT projects, but a large chunk of what tends to happen can be mapped to the issues raised in this article. In a future post, we will look at some of the warning signs associated with a project 'at risk."


Copyright 2013, Stephen Lahanas