Tag Archives: Why projects fail

The Top 5 Rookie Mistakes in Software – #3 Techno Hype

technology.jpg

The Technology Dream

It’s just a tool, not a Strategy

It’s amazing how often technology gets confused and spun as a marketable feature. It’s not uncommon for companies and governments, for instance, to state that they will “Leverage Technology” as a business strategy. In the same breath, they’re also going to reduce unemployment, clean up the environment and fix the economy. Sure they will.

There’s an exciting appeal to ‘technology’.  There’s still a mystery and newness to even the word that elicits a dreamy promise of endless possibility.  It’s impressive apps like Google Earth, Halo 3 or the iPhone that people likely think of when talking about technology; apps that look good, sell well, and entice people to get lost and obsessed in them.

Sexy apps, however, are built by clever people with a focused vision around capability, content and a dreamy interface. The fact that they leverage technology is almost incidental. It’s easy to get caught up in the excitment of the dream and forget that business is still business regardless of the tool you use.  The truth is, it’s not uncommon for both business people and technical people to miss the point that technology is only a tool. Without a purpose, that tool is just a means to an undefined end.

Without establishing a direction and purpose for a software product that is focused on boring old things like: User, Market and your Business; your technology dream will simply deflate into another expensive mistake rather than a hot app.

The Framework Dilemma

As technology professionals, we get caught up in the dream too.  I’ve been guilty many times of approaching business problems with a technical solution without stepping back and wondering if it’s truly the right thing to do. It’s easy to get wrapped-up in the world you know and use that as the solution to all problems. “Have you considered building an Application Integration Framework?” – Those were my words. It seemed like a reasonable thing to suggest. This guy’s media company had multiple products that couldn’t talk to each other and ‘Integration’ was high on his agenda.

“NO! NO FRAMEWORKS!” – Was his response.  He even stood up out of his chair and leaned forward towards me pretty aggressively when he said it.

Wo, that guy was jaded. But I understand why now.  He quickly calmed himself and explained to me that a consulting company had sold him the same line a couple years ago. They spent those 2 years in, what I call, “a Dark Place”, just building a Framework. They didn’t consult with them about what the products do, or what the user needs, or business drivers, or the data or how this could tie into their overall technical strategy – nothing like that. They just built a framework.  It took 2 years of nothing tangible, but these consultants were finally kicked off the property. All there was to show for the $1.2 million spent was a bunch of code that had no business value.  I’m sure it was a brilliantly designed framework, but it didn’t do anything. I’m also sure there are thousands of skillfully composed frameworks out there sitting lonely on subversion servers around the world. I’ve personally participated in a framework or two that went nowhere. It’s a common thing for developers to want to do.

targeted.jpg

I don’t want to dismiss the importance of a proper architecture and framework; all software applications need a solid foundation. But they have to be built to fit the business need, and with a specific user-driven purpose.  Frameworks should be small, lightweight and grow with the product. Key to making sure that happens is: every aspect of a framework has to have a consumer. If someone on your team is building a component or framework or utility in anticipation of the potential of it being useful, that effort should be denied.

Technology For Technology Sake

My old boss used to have this tendency to wander into my office and recount stories about his past. He didn’t have all that much material, so his stories got repeated a fair bit – I didn’t have the heart to tell him that of course.  Anyway, one of his more riveting stories I got to know well, was about the specifics of a product idea of his that failed. It was essentially like this: a data service architecture that could connect to multiple databases; a domain layer that sat on top of that which reconciled data from these different locations; on top of that was a communication layer based on web services and finally there was a forms builder to create custom interfaces as the top layer of the product.  He thought it was such a great idea and would shake his head in bewilderment as to why it never went anywhere. “Well, what did it do?” I asked him one brave day. “It could connect to multiple databases.” Was his answer.

“To do what though?” I asked.

“Well, to do anything.” He said.

“Anything that needs multiple databases…” I said, to be agreeable; but really I just wanted to get out of the conversation.

So, who’s going to buy that? It’s a thing that doesn’t have any real purpose, except to say it serves a purpose behind an unknown purpose. A body without a head. I didn’t have the heart to tell him, of course, because he thought it was so awesome … and it was kind of his baby. But like a lot of people, he chose to build technology for technology sake, and didn’t appear to understand that that isn’t a product or strategy, it’s only a tool.

Chris Ronak

Advertisements

When your project fails, it IS your problem

As Technology Professionals, we have an obligation…

It’s pretty common for software projects to fail.  According to the Standish Group’s 2009 CHAOS report, only 32% of software projects succeeded over the past year. Not exactly a banner year to be sure; but even in a good year, it’s rare to hit more than 40% success. Whatever the reasons and wherever the fault may lie, these are disturbing numbers that I think we, as technology professionals, need to take ownership of and do our part to correct. (For a little background reading, have a look at this excellent IEEE paper about software failures).

It’s easy for a member of a software project team – especially developers – to up and bail out of a ‘disaster’ project situation and simply move on to another project.  There are plenty of opportunities out there for skilled technical people, so it doesn’t take much to just throw your hands up in the air and abandon the disaster for a more appealing career move.  It’s equally easy to ride-out the disaster and just show-up for work, and tune out the world around you.

The thinking, of course, is that it’s someone else’s fault, someone else’s problem and someone else’s financial catastrophe to sort out.  After all, you’re just a small player in a big machine.  It was probably a lack of requirements, poor leadership, lack of focus, too many changes, management issues, etc etc. that caused the failure, right? So, why should you take on any responsibility?

The trouble with that type of thinking is, Those People left to pick up the pieces of a software failure are left with a bitterly sour taste about the risk associated with investing in software.  They have to stand in front of investors, customers, regulatory bodies and other stakeholders to explain the multi-million dollar failure.  And you know what?  They are not happy with the 32% success rate in software projects.  It’s both expensive and it looks bad on their career.

And with all these software failures on the books, They may decide that, when faced with the prospect of investing in software products & projects – and technology in general – it is far too risky and their money is better invested elsewhere.  We really need to improve things.

So, without descending into a blame and fault discussion, let’s be honest about the burden of responsibility of software project success and failure.  While it’s true that the causes are rooted in many influences and situations in an organization, my goal in this discussion is to zero in on what we, as technology professionals, HAVE TO DO to avoid and repair the ongoing brutal legacy of software project failures.

failure-success

On the positive side, I truly believe that we’re getting better at building software. This is echoed in historical CHAOS reports from the Standish group, but it’s also something that’s evident in the many improvements and maturity in the world of software development: better tools, improved standards, and the emergence and more widespread adoption of Agile and accompanied development processes that reduce risk.

Part of the challenge is that there really aren’t any established standards in this industry.  Adopting standards is optional.  There are obviously scores of strategies to improve quality and the ability to reliably hit release targets, but it’s typically at the discretion of the development team and mostly overlooked … which is largely why we’re at a 32% success rate.

So, to start with: whether you’re a manager, developer, product owner or business person, here’s a bare-minimum list of what your software development team should be doing to improve your ability to build and ship quality software:

  1. Continuous build on an independent build machine.  Check out Continuous Integration for more.
  2. Improve team communication through daily Stand-ups or Scrums
  3. Integrate QA into your development team and development cycle
  4. Keep your software in a continuous working state. Only the code that’s checked-in should be considered as valid working code.
  5. Ship your software product often – like every week. Even if it’s just to internal stakeholders.
  6. Divide the release cycle into manageable chunks (sprints, iterations)
  7. Remove barriers between the technology teams and the rest of the company or to customers. Invite users/stakeholders to regularly see your working software in progress
  8. Adopt best practices around: peer reviews, QA, exception handling, coding standards.

Each of these simple process improvements vastly reduce risk and increase the chances for success.  These examples are only a scratching of the types of methodology/process upgrading that teams should be adopting, but I believe if ‘most’ teams were to do only those things, the number would dramatically move from less than 40% to well over 50% success.  Still not great – and I’ll address some more deep reaching improvement concepts in upcoming discussions – but if more teams and technology professionals were to adopt a sense of ownership in improving the global perspective of software project reliability, we can avoid a most certain backlash in the availability of technology investment dollars.

Chris Ronak