Home Leadership Skills 'Business Value' as a Factor in Software Design Projects
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
'Business Value' as a Factor in Software Design Projects Print
Over the past few years I have observed a growing tendency towards designing software which is too good.

That's right -- too good.

What is too good? Software which dramatically exceeds business requirements. This may include excess functionality, over documentation, or too much focus on quality. Some people may challenge me by saying that none of these things are bad -- they are "value add". I would counter by pointing out that if business requirements are exceeded then any resulting impact on schedule or budget performance may, in fact, be a negative "value" delivered to the business.

It is easy to fall prey to the temptation to over-deliver. Foremost, is the belief that by over-delivering on functionality or quality we will increase customer satisfaction. This is fueled by a growing number of high-end software design and development tools which make it easier to add extra features (especially in GUI design). Of course there is always the temptation of the designer to try to make something better than he did last time, and trade publications and speakers at conferences tout the "value" in using the newest techniques and technologies to do so. It is this "value" concept which creates the problem.
Is a software designer or developer the best person to assess the value of using different technologies or techniques?

Value Engineering is the name of a discipline widely applied in the construction and engineering industry, but little seen in I/T. In exercising this discipline, a designer will assess the business objectives behind a project and the specific business measurements that will be used to determine success. The designer will then identify a number of alternate solutions which are all capable of delivering the business objectives. This identification process is key, and is where creative practitioners can differentiate themselves. Thinking "outside the box" is encouraged -- even required -- for successful application of the discipline. Alternate solutions are evaluated to determine how well they will meet the objectives, and then cost, time, and risk estimates are provided for each approach. A solution is then selected which will meet the business objectives with the minimum cost/time/risk profile, giving the "best value" solution.

In practice, this creates remarkably different solution designs that one would normally see. In one case, I worked with a team of I/T architects and senior software developers to develop a high-level solution design and implementation plan for a human resources intranet site for a large corporation. Aside from standard web pages, the requirements included a searchable employee directory, with dynamic organization structure reporting, and a number of other small applications automating HR processes. The design and implementation plan were prepared, and independent reviewers provided assurance that the estimates and approach were valid. The cost of the solution: over $650,000 and five months to implement.

I then brought in another team, experienced in value engineering, and gave them the solution design and plan prepared by the first team. Immediately, the designers began to see more efficient approaches. In the end, using the same underlying technology but a different development/implementation methodology resulted in a cost of $110,000 and six weeks to implement. This second plan was approved, and the project was successfully completed within the lower time and cost budget.

The result to the customer: the same business value delivered in 1/6 the cost and 1/3 the time.

It's not that the first approach was "wrong" -- it did provide an excellent solution -- it's just that it provided a solution that was "too good". There was functionality which seemed, to the first set of designers, as a logical requirement that was not included in the final solution as it did not directly support the underlying business objectives and thus drive measurable business value.
Also included in the solution was a "best practices" approach to software structure which may be what is promoted by the software industry, but again, provided no support of the underlying business value for the customer.

In another example, a web site with some simple non-secure transactional functionality was initially designed using Java servlets. An alternate approach was developed using the PERL scripting language. The second approach required a fraction of the cost and development time. The first set of designers resisted the PERL approach: the solution is not object-oriented, provides for no code reuse, is based on an older technology, does not provide an application server environment which could be leveraged in future phases as e-commerce and other functionality is added.
What they did not know, however, was that the business owner (the Vice-President of Marketing) was quite happy with a "throw-away" solution, as the web site was only going to be a temporary measure to meet some marketplace expectations while the company was negotiating a joint venture with another company with a robust, leading-edge web solution.

Software designers should not pretend to understand all the aspects of a company strategy. In many cases, some very important factors are kept secret and not passed down through the organization. Factors like impending acquisitions and mergers, or impending strategic alliances.

Why do we consistently try to "build a better mousetrap" anyway? In some cases, such as core banking systems which will be around for many years, this makes a lot of sense. In others, however, such as e-business or web implementations, this may not be the best approach. Designers focus on object-oriented techniques to maximize the possibility of reuse, but in the fast-paced e-business world, how often are we building from scratch or rebuilding anyway?
Technologies are often evolving so fast, and companies are often switching technology platforms, leading to situations where there is little likelihood of any code being reused. Where this can be anticipated (such as knowing that the next release of a core application is not backwards-compatible, resulting in rewriting of all customizations) very different technology decisions may be made in the short term, driving better business value.

I know of a few dot.com developers who were told to build their underlying applications quickly, not worrying about reusability or building open interfaces into the applications. The business objective was to get a working application to market quickly, to capture market share, so that the next round of venture capital financing could be completed. If the developers rebelled and built the applications "the right way" then the company would have missed its market window of opportunity, not received the required financing, and the developers would have been out of a paycheck.
In the end, the company was going to rebuild the applications anyway, using a different platform, to better handle larger transaction volumes. The best business value for the company was to build throw-away applications which could be developed quickly and cheaply.

When analysing the business case behind a project, try to first satisfy the elements which provide the shortest return on investment cycle. Don't focus on the long-term returns, since the environment is likely to change before then anyway. Don't sacrifice certain short-term returns for possible long-term gains which may never materialize.
It is best not to make these types of decisions alone. While it is difficult to explain some technical tradeoffs in terms that an aging CEO may understand, the benefits of doing so will be great, as you will have the support of the business, not just the technology department. I/T has been traditionally seen as a cost centre for most companies, but if I/T learns to talk to the underlying business value, in terms that a CEO will understand, then I/T will be seen to be driving bottom-line value.

The value engineering approach does not try to "trash" high-end tools or technologies -- it just tries to make the trade-offs understood by the business decision makers. It tries to ignore tool or technology biases and gives data on creative alternatives so that the right decisions can be made. All I/T project managers should learn this discipline so that they have another tool in their kit to help them better communicate with (and get buy-in from) project sponsors.

2002 © Kevin Aguanno, PMP, MAPM

Kevin J.J. Aguanno,
IBM Certified Senior Project Manager,
Canadian Project Management Knowledge Network (PMKN) Leader
Business Innovation Services
IBM Canada Ltd.
Phone: (905) 316-8966
Fax: (905) 316-2535
Pager: (416) 600-0794
This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.