Why Would You Drive Off a Cliff?

Thelma and Louise found themselves driving towards the edge and in a moment of elation thought “what the hell” and put their foot down on the accelerator even harder! Why did they do it? Why did they choose to drive off that cliff when the result has a 100% chance of being really, really bad? In their case it was a trail of abuse, shootings, death, misery, and other misfortunes that made them feel they were out of options and had no other place to turn. Whether you agree or not at least there’s some logic behind the choice.

Today when most new software projects are begun, those involved plan them out with the same approaches used on previous projects even though statistics show that software projects conducted using traditional approaches continue to fail at a rate of 80%. Once the kick-off meeting concludes and everyone learns their roles and assignments, they trundle off to their cubical, fasten their seatbelt, swivel toward the cliff in the distance, and press down on the gas pedal. Why do they choose to drive in this direction when the result has an 80% chance of being really, really bad? The team isn’t usually driven to this choice from shootings, death, and misery. Most organizations actually seem to be comfortable embarking on new project journey’s with these terrible odds. Why do they do it?

I’m interested in your thoughts and ideas as to why and what you think can be done to improve the success rate? Based on your feedback, let’s explore some ideas on how to remedy the situation.

---

Building A New Routine

You know when you hit the gym for the first time in ages? Or maybe for the first time ever? You stand in front of the mirror and have your measurements taken by a trainer, who then gives you some basic instructions for a set of exercises you’ll need to do in order to change your health, and possibly your life. It’s daunting, and you know that there is a tremendous amount of work ahead in order for you to meet your goals, but you also know you have to do it.

 

From the conversations I’ve been having lately, it seems that Fortune 500 organizations are standing in front of the mirror, feeling this pain. They have been stuck in a rut; doing things the way they have always done, deriving perhaps comfort, but no satisfaction, from their routine. In most cases, they know that they are flawed, but often they just can’t jolt themselves into a making change. And just as the impetus to start an exercise program is driven from concern over impending health issues, the need to effect change in an organization is driven from the fear of being left behind.

 

With exercise, the impetus for change can be an image of your future, fitter, better performing self; or perhaps you’ve had a health emergency and have realized that you can no longer continue your current way of life. In either case, you made it to the gym, and looked at yourself critically in the mirror. Discipline is required and at first the exercise is awkward, inconvenient, painful and difficult; your resolve is severely tested. However, if you persevere, your routine becomes the new “norm” and very soon you cannot do without it. You won’t look back (unless it’s to laugh at your former, weaker self).

 

Due to globalization, regulation, new competition, and technology innovation, corporations must rapidly respond and adapt their business to remain relevant, cost-effective and competitive. On an organization’s “first day at the gym” it has to take a hard look at why projects are failing due to poor requirements. The first “exercise” (and first opportunity for new agility) is to eliminate the rework tax, and to modernize the “software planning and requirements” process. This precedes all other software activities and is therefore a good place to start (and with high potential for a positive “ripple effect” downstream).

 

Organizations envision that their new “routine” will result in system agility and flexibility that will allow business applications to adapt and change at a faster rate than was ever contemplated before. Old habits need to be unwound, and new practices will make them fitter and healthier. Changing the economics of software projects starts with an honest look in the mirror.

 

The customers and prospects I’ve been conversing with lately all seem to be standing in front of that mirror in the gym contemplating that first exercise. And if not, they are at the very least looking for a gym membership.

 

I would be interested in your thoughts and comments on “embracing change” and “building a new routine”.

 

---

Optimizing Software Economics Through Better Requirements

Hi, I'm David Nyland and I am embarking on this new blog with a goal of starting a dialogue with software leaders and managers about “changing the economics of software development” driven by an investment in improving their overall approach to requirements.

I want to start by introducing the topic, and then I have plans to continue with an extended series of blog entries covering:

• Where to start – process first, tool first, process/tool combined
• How to justify the investment and develop an ROI

So let’s start today with introducing the topic – “changing the economics of software development – driven by requirements”. Since 2008, give the economy, there has been a huge focus on IT cost reduction, elimination of waste, and improved efficiency. Many waves of IT cost-cutting have been completed, lower priority projects have been suspended, current projects have been re-prioritized and re-planned, and there has been a continued push to move inexpensive development and testing IT activities offshore. Most of the “low hanging fruit” in terms of IT economies and efficiencies have already been realized. The unfortunate impact of the cost-cutting and extreme focus on efficiency is that project backlogs have escalated and innovation has slowed-down. The result is that important modernization projects that have the potential to drive a step-change in further cost reduction, and important new applications that drive revenue and customer services, are de-scoped and/or delayed. This same impact resulted from the 2000-2001 recession when (as Gartner put it in a 2008 press release) “many organizations (in the last recession) took a hiatus for a year or two from investing in application modernization ….. exacerbating obsolescence and stretching the patience of the business stakeholders”. IT leaders cannot rely on the economy improving in the foreseeable future, so to tackle the escalating backlog, to accelerate innovation, and to drive further savings and efficiencies, IT leaders need to target new areas of IT improvement.

Now let’s take the big 4, program/project/portfolio management, requirements, development, and testing. Aside from requirements, the others have been a constant IT focus (in terms of process, people, and tools) for over a decade, evidenced by mature capability Centers Of Excellence (CoE) that have been established within major organizations for these job roles and toolsets. Similarly, CoE’s and CoE setup consulting offerings now exist from the major SI’s such as Accenture, CapGemini, CSC etc and they have been in place for some years. In the case of requirements – well this is “virgin” territory for most organizations and SI’s. The problem is that many IT leaders do not yet know that new transformational software solutions exist that can underpin a new maturity and consistency in requirements competency and that will deliver major new economies and time-to-market benefits that are already being realized by those that have been the “early adopters”.

Now at this stage in the process, I want to reference some recent research completed by respected analysts Lisa Dronzek and Theresa Lanowitz at voke Research, and Mary Gurush at Forrester. An extract from a recent August 2010 report from Lisa states “Requirements are turned into software that is meant to completely differentiate the business – with so much at stake, the cornerstone of software is requirements definition. By making requirements strategic, you improve the chances of software delivering true competitive advantage”. Lisa and Theresa in a separate August 2010 report go on to comment “We weren’t surprised to learn that leading IT organizations now view requirements definition and management as a cornerstone to the success of their overall software development process. Through a combination of process change and tools implementation and training, many are seeing a dramatic improvement in the economies of their software development projects, which is allowing them to improve their overall business performance and competitive advantage”. Mary, who is very focused on the requirements space, in a June 2010 report commented that “smart application development leaders are catching on: Good software requirements are critical to delivering high-quality software. There is a greater focus on eliminating waste, increasing adoption of Agile approaches, and the ever-growing global dispersion of development teams that is powering the need for improved team collaboration. These shifts are driving significant change in the requirements tools market, which continues to evolve rapidly.” Now, these are great observations about the current state of requirements. So, the real question is “what is different now”? At Blueprint, and consistent with Lisa, Theresa and Mary’s observations from their customer research, we have come to learn that the key is the proper use of requirements definition and management software. As we look into our Blueprint customer base of F500 enterprises, we see many early adopters of requirements definition and management software tools, and they are experiencing dramatic improvements in cost efficiency, time-to-market, reduction in project backlog, and improved relationships between business and IT organizations. We have observed this on many types of customer projects from legacy application modernizations, package systems deliveries, custom software/web developments, and in a diverse range of industries including financial services, government, healthcare, pharmaceuticals, manufacturing, and commercial software businesses. Our product, Requirements Center, approaches requirement definition and management with a heavy focus on visual approaches to requirements authoring and validation, backed-up by efficient requirements change management and seamless transformation of requirements into the development and testing platforms.

So the stage is set – 1) Requirements and requirements tools are an area of focus that can drive strong new economies in the software development process, 2) Analysts have researched the early adopters and have validated the benefits – “the cat is now out of the bag”, and 3) there is a path forward to investigate, evaluate, justify and deliver the same results as evidenced by our customers.

Watch this space as we take this journey to realizing new economies – and please join me in this discussion!

 

---