, University of the Western Cape
Pages: pp. 15-17
Abstract—What critical factors played a role in your last project success? Join us on this intellectual journey from software engineering to business strategy.
Everyone who ever taught project management seems to have a favorite disaster story, whether it's the new Denver airport baggage handling system, the London Stock Exchange, or the French Railways. Many of us would point to deficiencies in the software engineering activities that seemingly guarantee failure. It is indeed important that we understand how to engineer systems well, but we must also consider a wider viewpoint: success requires much more than good engineering.
We must understand why we are engineering anything at all, and what the investment in money, time, and energy is all about. Who wants the software? In what context will it be applied? Who is paying for it and what do they hope to get from it?
This special focus of IEEE Software takes that wider viewpoint and examines different views of how we can achieve success in software projects. The arguments and projects described here are not solely concerned with software but with the other deliverables that typically make for a required outcome: fully trained people; a new operational model for a business; the realization of an organizational strategy that depends on new information systems.
There is a hierarchy to these things. I have always admired John Zachman's framework for software and systems engineering. 1 It is not new, but it provides a structure that organizes the criteria for success into the many layers that must be considered: the technology at the lowest level, the program code, the technical systems design, the user requirements, and the business systems—even the enterprise itself. I am always amazed that people can talk of an investment in technology—say a new server or a new network—with the assumption that it will solve business problems. Assurances of business benefits are offered with no consideration of the intervening systems design issues, or the business models that describe what actually needs to be done. I contend that this is not how things work, and the articles included here tend to support that view.
Through two review articles and three articles based on case studies, this focus section illustrates and informs us about the intellectual journey from software engineering to business strategy. The case studies are drawn from software "using" organizations as well as from "supply-side" software engineering companies. They are each quite different and help us to see the problems from different levels, from working engineer to senior business manager.
Perhaps it's best to start with some straightforward advice from someone who has seen it all. John Reel has distilled years of experience into a readable essay on critical success factors in software projects. If what you really want is just five good things to think about, read this and enjoy how he authoritatively explores ways to initiate, realize, and conclude software projects.
Each case study is taken from real life. The organizations involved may not be the same as the business you are in, but you should have no trouble in relating to their experiences.
The first looks at a single critical project in a military context: Buford Tackett and Buddy Van Doren explain how, to ensure success, the project adopted a strict engineering approach—even borrowing from systems design theories and methods. You may have seen a summary of the NORAD project in Scientific American; here you can read all about it and discover in detail how the project succeeded.
The second case is quite different. To find out what the Capability Maturity Model looks and feels like in practice, Brian Fitzgerald and Tom O'Kane look at a whole organization over several years. Having made it to level 4, Motorola's Cork, Ireland, facility failed to achieve level 5 in the first pass. Here you will find out about not only the critical success factors that led to level 4 but also the critical failure factors that tripped them up at the final hurdle. Considering how few organizations have gotten even that far, this is a fascinating insight into the real world of the CMM, its requirements, its risks, and its benefits.
Chris Holland and Ben Light examine a much bigger issue: how to succeed with enterprise resource planning projects. ERP systems are entirely dependent on software—yet ERP implementation depends on so much more than software. This is the way of the future for so many organizations: to re-engineer the whole darned company, based on the capability of large, complex software-based systems that in effect provide a model for how the company should work. This is about strategic objectives as well as operational ones.
Much of our effort to improve software engineering in recent years has focused on software metrics. Anyone who has been in the business for a while has heard of source line counts and function points. Some of us are old enough to remember Halstead's Metrics, but let's not reminisce.
Shirley Becker and Mitchell Bostelman have been exploring metrics for business and ways in which they map to more detailed (and possibly more familiar) metrics for projects. They draw on management theories to provide a fresh view, strongly oriented to the business context for projects. Here the project manager is promoted from engineer and bean counter to business manager. Is that what you want? Read the article and see what you think.
At the business level, project management is seen by some leading thinkers as the means to implement organizational strategy. 2 The organization that can link the cost and size of a software investment to business revenue and other high-level benefits will be successful, not just in developing software but in using it strategically as well.
Any of you working on the software supply side may be puzzled by the need to worry about business strategy. "If all I am doing is creating a new operating system release or a new database environment," you may ask, "why should I be concerned with business strategies in companies that just happen to use my new software?"
The answer is simple: unless software systems address real organizational needs, they will not succeed. Your project is bigger than you think: it has to deliver delight to all those people outside your organization who might depend on your product, not just to your corporate quality control executive. The project involves your marketing department and, of course, the final end-user customers.
If you work for software "using" organizations, you'll have no problem relating to the advice here.