The Industry commentary presented within this section of the SEPA, 5/e Web site presents selected articles reprinted (with permission) from The Cutter IT E-Mail Advisor, one of the weekly e-mail bulletins from Cutter Consortium. Each of Cutter's E-Mail Advisors provides data, analysis, and advice from industry experts.
Research Briefs and the Cutter Edge are free services, available to all qualified IT and business professionals. To register for any of Cutter's E-Mail Advisors, visit
http://www.cutter.com/consortium/index_e-mail.html
It should be noted that many of these papers are opinion pieces, and I (RSP) don’t necessarily agree with every opinion presented. However, each paper presents useful commentary that may encourage you to research a topic more fully.
The following commentary is presented for your interest and enjoyment:
Management-Oriented Commentary
The Software Industry
Software Process Issues
Project Management Issues
Software Measurement Issues
Technically-Oriented Commentary
Requirements Issues
Components and Reuse
Technology Issues
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
It is clear that technology, business, society, safety, security, and the well-being of nations are now "fused" together. On a global scale, technology, information, and knowledge are key determinants of the success and competitiveness of a nation. In
short, the landscape of competitiveness has gone through a major transformation into what is called the current "information age."
In the introduction to the *1998 World Competitiveness Yearbook* (Institute for Management Development (IMD) 23, Ch. De Bellerive, P.O. Box 915, CH-1001 Lausanne Switzerland; Tel: +41 21 618 0251, Fax: +41 21 618 0204, e-mail: wcyinfo@imd.ch), Professor Stephane Garelli identifies key issues related to these new frontiers of
world competitiveness:
Furthermore, this same analysis recognizes the impact of technology on global competition and marketplaces:
Taking these observations one step further, the IMD analysis translates them into 6 dimensions that encompass the new management competencies of competitiveness:
It is clear from these points that technology and technology management on a global scale are key components of competitiveness. Organizations, even those that are not multinational in scope, must look beyond their own borders and boundaries to achieve the economies, efficiencies, and leverage needed to be competitive into the next millennium. This is where a fundamental understanding of global software economies comes in.
Just as in the industrial economy where global sourcing has changed the economics of production and distribution -- the textile, steel, automobile, and electronics industries are excellent examples -- the economics of software product development and software systems development are changing and are about to change more radically than ever imagined. All 6 of the management disciplines identified by IMD must be reinterpreted in the context of information technology and software economics.
Howard Rubin
Senior Consultant, Cutter Consortium
http://www.cutter.com/consortium/consultants/hrbio.html
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
In the current pro-outsourcing environment, it is difficult to obtain clear, hard evidence to support the argument against outsourcing. Clearly, an organization that has been very public in justifying outsourcing on the basis of reduced costs would be very reluctant to go public with the increased costs that it has experienced as a result of outsourcing. However, our group has seen the following outcomes among many of our clients.
Higher Costs
Certainly in the area of process work (which includes computer operations and support), the Outsourcing Institute's surveys indicate an average of 9% cost reductions. However, in the outsourcing of project work, the results are more mixed. In fact, experts such as Bryam Johnston now argue that in IT areas, cost reduction should not be the prime reason for outsourcing. There are many factors that explain either no change or an increase in IT costs upon outsourcing. However, in our experience, the most significant is that internal IT project groups often worked 30%-50% additional effort, which was treated as noncosted, unpaid, and bonus. It is our experience that few, if any, outsourcing companies will tolerate those levels of unpaid and uncharged work..
In addition, there is a clear profit motive from the outsourcing company's perspective. Unless substantial cost reductions are achieved through economies of scale, reuse, and the like, the outsourcing organization's need for profit margins of at least
20%-30% must lead to increased costs. Finally, outsourcing organizations typically have much more highly refined and focused cost-tracking systems, which lead to previously untracked costs being charged back to the client organization.
Risk Exposure
There are substantial risk exposures associated with IT and other project work outsourcing. The three key risk areas are loss of control of major projects, potential financial litigation, and loss of intellectual capital. There have been a number of very public litigation cases resulting from outsourcing. In Australia, two examples are the federal government and KPMG and the New South Wales government and IBM. However, anecdotal evidence (from extremely well-informed sources) reveals that there have been a number of major litigation suits between major private-sector organizations and outsourcing organizations that have received no publicity. Clearly, it is in the interest of both parties in a failed outsource arrangement for the failure not to become public. Needless to say, contract litigation lawyers and expert witnesses are experiencing a growth market.
Dis-economies of scale
This is an extremely interesting negative factor. Basically, the smaller and less high-profile the outsourcing client, the larger the incentive for the outsourcing organization to downscale the attention the client receives. Given the size of most outsourcing organizations, the client may in fact receive more bureaucratic and unresponsive service than it received from its ex-internal IT group. In Australia, most outsourcing organizations are local subsidiaries of international organizations and are often restricted by global priorities, rules, and policies.
Limited Access to Knowledge Base/The "B Team" Syndrome
This is a related factor to the previous one. The client organization's access to worldwide experts is often constrained by the fact that they are working on "more strategic" clients or projects. In addition, many outsourcing arrangements have started with the "A-team" being involved with the initial negotiations and projects, but as the contract proceeds, the outsourcing organization uses the contract as a vehicle for placing the "B-team" and trainees. This practice is encouraged by poorly developed contracts that do not stipulate the skill and experience levels required from the outsourcing organization.
There is a further argument against the "access to higher skills" justification for outsourcing, which is that the explosive growth of outsourcing has severely stretched the available "talent pool." Simply put, there are not enough real experts to meet the demand.
Loss of Intellectual Capital
Of all the negative factors, loss of intellectual capital is probably the most serious and the least understood by the executives making the outsourcing decision. The concept of intellectual capital is relatively new and is still gaining acceptance in mainstream management theory. As discussed by Thomas Stewart (Intellectual Capital, Nicholas Brealey Publishing, 1997) and Karl Erik Sveiby (*The New Organizational Wealth*, Beret-Koehler Publishers, 1997), there are two primary types of knowledge: explicit and tacit. Explicit knowledge is published and public, while tacit knowledge is "in the heads of the experts." In the IT area, very little knowledge (including the knowledge about existing production systems as well as the knowledge about managing and developing new systems) has been made explicit. As a result, the loss of IT personnel associated with outsourcing leads to a loss of tacit intellectual capital and capability. As has been documented on many previous occasions, the best people leave first, as they have greater options, leaving a "averaged-down" group for the outsourcer to recruit.
Loss of Control of Core Activities
The entire concept of "core" versus "non-core" processes reflects the process-versus-project work issue. Traditionally, the process work, or business as usual, was the core activity. In a bank, for example, the branch network and the product distribution chain were the core business. However, as numerous management gurus have observed, the core business in the new organizational environment is the development of new products and creative client relationship-building mechanisms. Information technology and project development are central to these new core activities. By outsourcing the people and intellectual capital required to develop new products, services, and systems, many organizations risk losing control of their future. They are outsourcing the new core of their business.
Conflicting Agendas
Shared values and loyalty are irrelevant in an outsourced relationship. The focus of the client organization is reduced costs, and the focus of the outsourcer is profit -- clearly a conflict situation. Unless the outsourcing contract has been designed to minimize this inherent conflict (see later), the size, fee structure, reward systems, and global reach of typical outsourcing organizations will generally place the client organization's agenda at risk. There are few incentives in the typical outsourcing relationship for the outsourcing organization to "go the extra distance" for the client.
Rob Thomsett
Rob Thomsett is a director of The Thomsett Company and Senior Consultant on Cutter Consortium's Business-IT Alignment Advisory Service. Rob is the author of *People and Project Management* (Prentice Hall, Yourdon Press, 1980) and *Third Wave Project Management* (Prentice Hall, Yourdon Press, 1993). He can be reached by e-mail at RobThomsett@compuserve.com, or at http://www.ozemail.com.au/~thomsett
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
It should come as no surprise that in postmortems of failed IT developments, we regularly find that project risk assessments were either poorly performed or nonexistent. It is axiomatic that IT developments underestimate the obstacles that they are likely to face, and failed projects clearly do so.
Interestingly, we find that poorly preformed risk assessments are found in tandem with poorly performed benefits analyses in IT development failures. Experience has taught us that insubstantial benefits analyses create substantial project risk, and are in fact
leading indicators of future IT/business misalignment. Organizations that routinely perform poor benefits analyses are the ones with high levels of IT project failure, underperforming projects, and misalignment.
Consider what occurs when benefits analysis is done inadequately. First, project objectives are ambiguously stated in terms of market need, competitive pressures, and the like. Since these objectives are ill-defined, they are not measurable. Without measurable objectives, it is difficult to define proper control points for the project, especially in terms of a visible threshold where the cost of the project exceeds its benefits. Without this threshold, it is impossible to say what is and isn't "too risky." Thus, attempting to make rational decisions later by doing a risk assessment is a worthless exercise.
Second, the project is sold to senior management completely in terms of its cost and schedule. These, of course, are defined very aggressively since they are now acting as surrogate project benefits. The assumption is that if the cost and schedule targets are met, then, ipso facto, some benefits must have been produced by the project. Aggressive cost and schedule targets mean the project is undercapitalized from the start.
Third, because the project benefits are vague, senior management gets a bit worried. If it doesn't kill the project outright, senior management will likely do three things because of the charade: speed up the project to gain the "benefits" earlier, take some of the resources away as "management reserve," and add some unplanned-for business objectives to the project. Each action, taken in the name of increasing the project's benefits and reducing risk, serves to do the opposite.
With mathematics of failure completed, it's only a matter of time before the project's dance of death begins. If project cancellation is somehow avoided, the result is usually a crippled IT system that is over budget, late, delivers little if anything of useful value, and perpetuates misalignment.
If your organization continually has trouble achieving alignment, review your IT failures and underperforming projects. They will show you whether poor or incomplete benefits analysis is contributing to your misalignment. Once the project benefits are understood, then risks can be assessed and managed with some hope of success.
Robert Charette
Robert N. Charette is president of the ITABHI Corporation, an international risk management consultancy. Dr. Charette is an internationally known author, lecturer, and risk management advisor to the *Fortune* Global 100. He has authored over 40 articles and several standard texts on the subject of managing risk. Dr. Charette can be reached at Charette@erols.com.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Perhaps the most important thing we have learned from Y2000 is that we can successfully pull off a major project with a defined deadline and potentially catastrophic results for failure. However, in many cases, we did so by carefully defining a strategy that would provide success, and not biting off more than we could realistically chew. The few reports of real Y2000 failures we've received have all
fallen into the category of sites that chose to replace an old system, started too late or with a problematic specification, and found that delivering a finished product on time was not realistic. Sites that aligned their goals, resources, and technical strategies
in the context of containing real risk to the business succeeded.
As we enter the new world of e-business, we need to keep this lesson firmly in mind. E-business includes both opportunities and real risks to your business, but of very different kinds. On the one hand, if your area of business is vulnerable to the "winner take all" effect, then your company is in a fight to the death, and you need to mobilize resources and management attention just as you did for Y2000. On the other hand, if you are not vulnerable in this way, then e-business can be approached cautiously and in stages, giving you time to learn without overcommitting resources.
A potentially more serious risk to the business involves approaching e-business as another way of doing what you do now. E-business is about fundamentally rethinking how your business operates, both internally and in your market. The Internet represents a precipitous drop in the costs of communication and barriers to entry, particularly for service companies and product companies with high-value/low-bulk output. The Internet requires you to focus on delivering what your customers really want, not what you think they want or what you can get them to want. Service, quality, and immediate response are of utmost importance.
Changing the logistics of your company operation may be a component of success in e-business. Among our clients, we see e-business operations growing at rates of 25% or 50% per month! Sometimes that involves cannibalizing the old business, sometimes not. Is your business process prepared to deal with such growth rates? Is your capitalization adequate for the investments required?
Changing the logistics may be a piece of cake next to changing your corporate mind-set. Consider one strategy employed by a few brave companies in sectors where this makes sense: starting a listserv open to both clients and prospective customers. This can give you a gold mine of information about what your customers are thinking, good and bad, about what you deliver and what they would like to buy. Warts are soon identified and can be corrected, for an inexpensive route to continuous quality improvement. Can you imagine this happening in your company? And this is just one example.
Now, where does IT fit in this? First, we have to emphasize the "I" in IT. Too often, IT is just a new name for data processing. IT has to become an operation where data has value added to become information. This information has to be integrated with marketing and product/service delivery in a way that is congruent with the key attributes of the Internet: I want it now, I want it to work, and I don't want to be hassled in the process, or I'll go elsewhere. Understanding this fundamental issue can result in the business thriving in the new economy; conversely, failing to understand it can mean a competitor that does can lock your company into the old economy.
Second, e-business is not just about a Web-enabled portal into your current applications. If you are going to have a retail application, it has to be usable by people who are barely computer literate. A very large fraction of retail transactions over the Web are never completed because ordinary people are unable to navigate the process to completion. Think of that: you have attracted a customer to your Web site, they want to buy your product, but they give up because it's too hard for them. The solution for this is in the area of ergonomics, but applied to software rather than chairs and desks. Do you have a software ergonomist on your staff? Should you have one? What are the business risks if you don't?
Finally, IT needs to lead on this subject. If management becomes committed to e-business but continues to think of IT as data processing, it will look to buy a solution from the outside. Such a solution may or may not provide what the company really needs, but will management be able to tell? Here is a major risk to the business that only IT can ameliorate: going a long way down a dead-end road. Only IT has enough knowledge of the business and of the technological issues to avoid dead ends.
Don Estes
Senior Consultant, Cutter Consortium Business-IT
Strategies Advisory Service
http://www.cutter.com/consortium/consultants/debio.html
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
SOFTWARE DEVELOPMENT DIMENSIONS
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
These days, the direction in which to take software is far from obvious. Let us just list some of the complications:
Dizzy yet? Let's go on.
Requirements Capture
Given a rough idea of what to build, stakeholders and developers face the task of converting that concept into detailed form. As the effort progresses, however, both sides learn more about the real-life application. What they learn is that it is more complicated than they thought originally. As they learn more about it, the requirements keep changing. Constant change is a "dimension" of software development.
Functional Design
The requirements have to lead to an overall pattern of what the software system is to be. This architecture should not only guide the current development cycle, but should be good for several later generations. In other words, the architecture and the resulting system should be capable of adaptation to needs now perceived somewhat dimly.
Risk
Doing something not fully defined over months and years into the future is accompanied by risk. The definition of what to build will evolve; technical risks that were not foreseen may appear; business risks, such as competition getting there first, may materialize.
Staffing
Software development is carried out by people, involving all the well-known complications that accompany the human element, such as hiring, training, pay scales, motivation, morale, turnover, and disputes. Having a path moderates at least one source of disputation.
Process and Tools
The Software Engineering Institute calls its Capability Maturity Model Level 1 "ad hoc" because it has no repeatable process. But there are software development processes and they make a difference.
Economic Constraints
All this has to be done within business limits of cost, effort, and schedule, and has to meet a quality goal.
Management
Back in 1992, when we published *Measures for Excellence*, Larry wrote: "Similarly, on the basis of my own consulting experience, management is high on my personal list. I used to put tools at the top. Now, I think the influence of management is much more important. Management can make all the other factors come together.
Larry Putnam and Ware Myers
Lawrence H. Putnam, Sr., is the president and founder of Quantitative Software Management. He can be reached at Quantitative Software Management, E-mail: qsminc@compuserve.com.
Ware Myers has been a contributing editor of *Computer* magazine since 1976 and of *IEEE Software* magazine since its beginning in 1984. Mr. Myers can be reached at 73153.1762@compuserve.com.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
WHAT MAKES SOFTWARE PROCESS IMPROVEMENT SO HARD?
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
If you cannot truthfully say, "I am building software today as well as software can ever be built," you should be looking for a better way. This is the essence of software process improvement (SPI). Despite the apparent simplicity, many software organizations struggle to achieve significant and lasting improvements in the way they conduct their projects.
I see five major reasons why it is difficult to make SPI work. First, insane schedules leave insufficient time to do the essential project work, let alone time to investigate and implement better ways to work. Just as manufacturing industries realize their equipment must be taken off line periodically for retooling, preventive maintenance, and installing upgrades that will improve productivity or quality, a focus on SPI is necessary to upgrade the capabilities of both individuals and organizations to execute software projects. Of course, you can't shut down the software development machine, so the upgrading has to be done in parallel with production work. Process improvement must be integrated with development as a routine way you spend some of your time. It is always difficult to find the time, but I know of one Web development project that takes a few weeks between releases to explore new technologies, experiment, and implement improvements.
A second obstacle to widespread process improvement is that many software practitioners aren't familiar with industry best practices. My informal surveys at conferences suggest that the average software developer doesn't spend much time reading industry literature. Programmers may buy books on Java and COM, but don't look for anything about process or quality on their bookshelves. The industry awareness of process improvement frameworks such as the Capability Maturity Model (CMM) has grown in recent years, but effective and sensible application still is not that common.
Some organizations undertake SPI for the wrong reasons. An external entity, such as a prime contractor, demands that the development organization achieve CMM Level X by date Y, or a senior manager decides to climb on the CMM bandwagon. Someone told me recently that his organization was trying to reach CMM Level 2, but when I asked why, he had no answer. He should have been able to describe some problems that the culture and practices of Level 2 would help solve, or the business results his organization hoped to achieve as a benefit of reaching Level 2.
A fourth barrier to effective process improvement is the checklist mentality, a rigid and dogmatic implementation of the CMM or other SPI framework. Managers and change leaders should realize they need to change the culture, not just implement new technical practices. New processes must be flexible and realistic. I know one company that mandated all software work products would be formally inspected, which is a great idea but not a realistic expectation for most organizations. The company's waiver process will run overtime, and practitioners may play games to appear as if they are complying with this unrealistic policy.
Finally, organizations may claim the best of intentions but lack a true commitment to process improvement. They start with a process assessment but fail to follow through with actual changes. They devote insufficient resources, write no improvement plan, develop no roadmap, and hence achieve a zero return on their SPI investment. Managers lose interest, practitioners conclude it was an idle exercise, and frustrated process improvement leaders change jobs.
How can you avoid these pitfalls and achieve the kind of process improvement successes that some organizations have reported? First, recognize that SPI is an essential strategic investment for the future of your organization. Focus on the business results you wish to achieve, using SPI as a means to that end, rather than an end in itself. Expect to see improvements take place over time, but don't expect instant miracles. Thoughtfully adapt existing improvement models and industry best practices to your situation. Treat process improvement like a project. Finally, remember that the bottom line of process improvement is that the people in your organization are working in a new way that yields better results. You can make substantive improvements in the way you build software; you have to.
Karl E. Wiegers, Ph.D
Karl E. Wiegers, Ph.D., is Principal Consultant with Process Impact in Rochester, New York. Previously, he spent 18 years at Eastman Kodak Company, where he held positions as a research scientist, software developer, software manager, and software process improvement leader. He is the author of the award-winning book Creating a Software Engineering Culture, as well as more than 110 articles on many aspects of software, chemistry, and military history. Karl is presently writing a book on software requirements, to be published by Microsoft Press in 1999. He is a frequent speaker at software conferences and professional society meetings. His URL is http://www.processimpact.com .
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
THERE ARE ONLY THREE LEVELS OF MATURITY
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Many IT organizations think "maturity" means moving up to a higher level in the Software Engineering Institute's (SEI) Capability Maturity Model (CMM). After all, a CMM assessment provides an objective report of how mature you are, right?
The problem is that the CMM framework wasn't constructed with input from your employees, your customers, or your management. It's a generic framework, not tailored to your specific organization.
So, am I saying that you should ignore the CMM? That would be immature, wouldn't it? Well, perhaps I'm not sophisticated enough, but for me, there are only three levels of maturity, and we are already familiar with them:
The first is childhood. Children know what they like and what they don't like. They try to do just what they like, and they avoid things that aren't fun. They focus on themselves, which is why parents have to work so hard to encourage them to consider the needs of others. Do you have any children in your organization? Sometimes an entire IT organization can be focused on their own "technical fun," such as (fill in the latest technical advance your people are dying to apply somewhere).
The second is adolescence. Teenagers are not children -- they know about others, and they worry constantly about what their peers think of them. They focus on others, which is why parents have to work so hard to encourage them to think about what would be best for themselves instead of just following the crowd. Do you have any adolescents in your organization? Sometimes a whole IT organization acts like an adolescent and does something because "everyone else is doing it -- and besides, it's a best practice."
The third is adulthood. Adults are complex. Sometimes they do things because they just want to, like a child. Sometimes they do things because others expect it of them, like an adolescent. But what is most distinctive about adults is that they decide for themselves what to do -- in full knowledge of the consequences. They choose to do what they do, because it makes sense for them. Do you have any adults in your organization? Sometimes an IT organization looks at what others are doing and chooses a different course because it's right for them -- and they know why it's right for them. That's true maturity.
So, to determine whether or not your organization is mature, step back from measurements such as CMM maturity levels and ask yourself if you know what your organization's specific problems are and how you decided on your approach to improving them -- what are you doing, and why?
Richard E. Zultner
Mr. Zultner helps software organizations improve with advanced quality methods such as statistical process control (SPC), quality function deployment (QFD), and theory of constraints (TOC). He can be reached at richard@zultner.com.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Most companies that adopt Internet technology do so without a long-term goal. It's a great adventure that starts with "we've got to have an Internet site, even though we don't exactly know what we'll do with it after it's up." Although there are thousands of
ISPs and probably tens of thousands of Web designers capable of building a corporate site for you, few (if any) are capable of advising you on the strategic alignment of Internet initiatives with corporate goals and IT directions. Many companies have numerous Web sites, often with conflicting messages, and few are aligned with any business process extending beyond a particular department or division.
The Internet Maturity Model
For the most part, organizations transforming from a traditional business to e-businesses take the same path. This is true for traditional goods and service providers who have made investments in computers and now want to take advantage of the Internet, not businesses specifically created around the Internet. These businesses can be defined as being at one of six levels:
Companies at Level 0 may have employees who use the Internet from home, but there's no corporate mandate or support for using the Internet for business purposes. Companies at Level 5 have reached the highest level, constantly looking for competitive advantage by introducing new Internet technologies or services.
This model suggests a standard migration path that can be used to evaluate a company's transition strategy toward e-business. If we know where we are, and where we're going, and know the steps to get us there, then much of what we do as an organization can be judged with regard to how well the actions align with these steps. For example, our personnel policies for recruitment should align with our (Internet) skill set requirements. Our choices in technology platforms should be aligned to support client-server computing and should include considerations for firewalls, transaction processing, security, etc.
We've got to consider each initiative not only on its business merits, but also on its impact on our long-range goals. If our "Web department" is different from our "IT department," we've got to bring them back together to take advantage of the collective body of knowledge. If we're going to outsource Web-related stuff, we've really got to understand its strategic value before deciding whether we want that to be in someone else's hands.
The IMM suggests that the move into e-business requires some fundamental changes in our organizations, from infrastructure changes to changes in the way we recruit and train personnel. There are enabling things we can do to create an adaptive enterprise, and there are things we can do that disable or inhibit this. Level-5 organizations are able to take advantage of new technologies and paradigms as they prove useful, companies at other levels will find it difficult to compete.
You'll hear more about the Internet Maturity Model in future Advisors, including such topics as moving from Level 1 to Level 2 (and from Level two to Level three, and so on), how to sustain Level 5, aligning recruitment and training for e-business, and aligning key business processes using Internet technologies.
John C. Scott
John C. Scott is a Senior Consultant in IBM's NY-NJ Metro Systems Integration and Application Development Practice. He's been an IT professional for 25 years, equally involved in stretching the technical possibilities (early document/image processing architect) and integrating the latest Internet technologies to enhance business possibilities. He can be reached by e-mail at john@johnscott.com.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
A NEW WAY TO LOOK AT PROJECT PLANNING
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
I believe strongly that it is of utmost importance for a project team to have a thorough, complete project plan before deliverables are created. But time and again, I watch even experienced project managers eager to "make a mark" jump into deliverable-based work before a work plan, timeline, and estimate is developed and agreed to.
I was talking with a colleague the other day who is dealing with a somewhat complicated contract negotiation (it isn't going so well, he says). One interesting thing he said was that when he reviews any potential contract or agreement, he looks at it from two angles. First, he reads it as it is printed. Then he switches the names of the parties around and reads it again to see what he thinks from the other side. If either of his readings is too biased, then he knows the true meaning of "agreement" is not being met and changes are required.
It occurred to me that we could apply the same kind of thinking to our project planning. After all, project planning should include a definition of, and agreement to, the project scope, approach, timeline, cost estimates, and so on.
Most people are familiar with the various types of contracts used by consultants, contractors, and outsourcers. In this discussion, I'm going to focus on two contract types: fixed price and time and materials. Fixed price, of course, means that the purchaser is guaranteed the exact amount of the invoice from the provider (provided there are no approved change requests). Under time and materials, a general agreement is formed by the parties at the start, but the provider simply bills the client for the time spent until the work is complete (there is no guarantee of a total amount).
I think project teams should take my colleague's advice at the beginning of every project -- before deliverable work is started. First, think of yourself as the provider, and decide whether you'd be happy to agree to a "time and materials" contract for the work defined so far. If you break into laughter because the scope is so loosey-goosey that you know this work (and therefore the billing) could go on forever, there's a problem.
Next, think of yourself as the purchaser of the services (the project work), and decide whether you'd be happy to agree to a "fixed price" contract for the work defined so far. If you again begin laughing because the scope is so loose that you'd be thrilled if the provider was silly enough to agree to a fixed price arrangement, there's also a problem.
Notice that this approach can work for both the provider and the purchaser. If each takes the four views (purchaser/fixed price, purchaser/time-and-materials, provider/fixed price, provider/time- and-materials) of the state of the planning results, prior to initiating the deliverable-based work of the project, many disagreements and misaligned expectations can be cleared up early in the project process.
This approach works for internal projects too. In these cases, the provider can be considered to be the IS department and the purchaser the project sponsor and/or sponsoring organization (the business client).
What do you think? Wanna make a deal?
Pamela Hollington
Pamela Hollington is a director for Rebound Consulting Ltd. In North Vancouver, British Columbia. She has more than 15 years of industry experience, including work in the financial, manufacturing, distribution, and retail industries, and successful consulting assignments in the public and private sectors. She can be reached at phollin@ibm.net.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
WHAT SOFTWARE MANAGERS MUST KNOW BEST
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
What must a software manager know best? What knowledge is both distinctive and crucial for success in managing a software organization? All managers need to know how to manage people; that's not distinctive to software managers. Knowledge of technology is distinctive, but there are many examples of excellent software managers who are not technical gurus. What is it that produces the results by which a software manager is judged? Their software process.
Software managers must know their development process. It is the most distinctive, and most essential knowledge for them to have. But what does it mean to "know" a process? Would being able to give a ten-minute talk suffice to demonstrate knowledge? No. All the attributes of the software product -- good and bad -- result from the software process that produced it. To plan that process, control it, and improve it, requires a detailed and visible understanding of the process.
How detailed? Well, if you look at commercial-grade software development methodologies, you'll find that many have about 500 tasks (defined at their lowest level of detail). If that seems like a lot, consider that these are comprehensive methodologies, so they cover all the technical activities, all the project activities, all the quality assurance activities, and all the management activities generally required to build commercial-grade software. Also consider that most of the planning, checking, reviewing, and approving activities often take only a few days (or less), and are done in parallel with other work. Some organizations have very nicely defined software processes with far fewer than 500 tasks, but most organizations I've seen suffer from a pronounced inadequacy of detail in their understanding of their own software process.
How can we gain the necessary detailed understanding and make this understanding visible, so it can be shared? Construct a model of your software development process: draw it out step-by-step, end-to- end, on a large whiteboard. I suggest you first use whatever process modeling method your development process has now. (We should consistently use the tools and techniques in our process upon our process to describe our process!) If you don't have a process modeling method, I suggest using data flow diagrams -- well-tested tools for modeling processes and well supported in CASE tools and diagramming software.
In just a few days, most of your software process can be modeled. (What is well known and agreed upon can be rapidly modeled. Where there are disagreements or unknowns will take longer....) In doing many such workshops over the years, I always find at least one "obvious" problem that wasn't obvious until made evident by the explicit model -- and yet has been around for years in the organization. Once the process problem is made visible, steps to improvement can be taken. Such quick fixes provide an immediate return on the effort to model the process. I also always find at least one person in the workshop, often someone new to the organization, who gains a new understanding of the process they play a part in.
But the model of your software process shouldn't be static -- done once and then discarded. Rather, it should be the basis for planning improvements: change the model so it becomes your plan, and then change the way you do software to match. Detailed understanding of the work we do is a powerful prerequisite for improvement.
The dominant difference in superb software organizations is not excellent tools, although they do have them. It's not "above average" people, although they do have them. It's not state-of- the-art technology, although they certainly keep current. It's their process -- which they have shared knowledge of, teach to those who join their organization, frequently measure, and improve continuously. That is what gives them consistently better results than what most software organizations can produce.
A great process produces great results. When will your software organization be great?
Richard E. Zultner
Richard "Show me the Process" Zultner helps software organizations improve their development process and apply self-improvement methods. Mr. Zultner can be reached by e-mail at richard@zultner.com.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
THE IMPACT OF SOFTWARE PROJECT MANAGEMENT ON QUALITY
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Software is becoming such an essential part of modern life that a radical improvement in quality is needed. For example, the doomsayers tell us that we'll wake up the morning after our Y2000 celebrations with overflowing coffee makers, phone bills
for century-long calls, unable to get money from ATMs, no TV or radio service, financial market meltdowns, grounded planes and stalled trains, and dozens of other problems. It's enough to make you want to stay in bed.
While the real "morning after" probably won't be this bad, the concern is widespread and growing. Frankly, we're embarrassed by the fundamental lack of confidence in software project managers that these worries highlight. Here we have a vitally important problem with a clear deadline, and there is an overwhelming lack of confidence that software project managers will get the job done on time with acceptable quality! Based on our dismal track record, the concern is well founded.
Quality problems and poor project performance are all too common. A worldwide survey we conducted a few years ago found that half of development projects fail to meet their cost and schedule targets, with typical overruns ranging from 40%-200% across several industries. This confirms the anecdotal evidence; most of us can name plenty of failures.
The good news is that we needn't accept a continued "no confidence" vote. There is new insight into why software quality is so difficult to achieve, and why software projects are so difficult to manage and predict, stemming from pathbreaking work in system dynamics modeling of software projects. Managers of critical projects at the end of this millennium and into the next can use these insights to gain control of their software developments.
The Importance of Software Project Management
Y2000 projects are only a special case of the challenges we've faced for decades: completing important development efforts on time, on budget, and with superb quality. As software becomes embedded in ever more products and services, successful management of development projects becomes a critical determinant of success in most industries. The lessons discussed here can help you succeed.
Why Is Performance So Miserable?
What is missing from most project management tools is an explicit identification of rework. Traditional methods treat each task within a project as discrete, having a definable beginning and end, with the work content either "to be done" or "in process" or "done." No explicit measure is taken of the quality of the work done, the release of incomplete or imperfect task products, or the amount of rework that will be required. Managers often end up fudging their estimates in a crude attempt to reflect the cost of rework. Lack of detailed attention to rework is particularly dangerous on development projects, which have a naturally iterative process of specifications, design, coding, and testing. Indeed, our analyses have shown that rework is often the majority of work on complex development projects. To accurately understand project status and avoid late surprises, we need a better way of measuring progress and understanding the development cycle.
The Rework Cycle: How Projects Really Work, and Rework
In our work, we have repeatedly observed a phenomenon we named "the rework cycle," which describes how development projects proceed. Think of each project unit of work as a Ping-Pong ball that can reside in any of several physical pools (boxes) and that flows through pipes (lines).
At the start of a project, all work resides in the pool of "work to be done." As the project progresses, people working at varying productivity produce "work being done." Unlike typical project analysis tools, the rework cycle also reflects the fact that work is "completed" at varying levels of "quality." Quality reflects the portion of work being done that is "work really done" and will not need rework. When quality is less than 100%, some work being done -- even rework itself -- will take a detour through the rework cycle.
Work being done that will need future rework lies for a period of time in a pool of what we call "undiscovered rework" -- work that contains undetected errors. For the moment, this work is perceived (and reported by traditional project control systems) as done. Most "rework discovery" occurs due to downstream efforts or testing, but months (sometimes even years) may pass before this discovery occurs! During this time, technically dependent work will have incorporated these errors and entered its own rework cycle. (Thus, downstream work becomes much harder if it is performed while upstream work is of poor quality. Good managers recognize this and plan accordingly.)
R. Bradley Burdick, Thomas W. Mullen, and Alexandre G. Rodrigues
Brad Burdick is a member of the Pugh-Roberts Associates practice of PA Consulting Group in Cambridge, Massachusetts, where he specializes in technology development and management issues for a variety of industries. Tom Mullen is a member of the Management Group of PA Consulting Group and has been part of PA's Pugh-Roberts Associates practice since 1985. Alexandre Rodrigues is a member of the Pugh-Roberts Associates practice of PA Consulting Group, where he specializes in project management issues. The authors can be reached at PA Consulting/Pugh-Roberts Associates in Cambridge, Massachusetts.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
SELECTING THE RIGHT TEAM SIZE: SMALL IS BEAUTIFUL
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Selecting the right team size -- small -- is the key to a successful project. By successful, I mean one that comes in on time, on budget, with good quality. Further, one that actually completes faster with less effort than the same project attacked with a large team.
In my past research I've shown that projects with 20 or more people used a lot more effort (person-months) than projects using 5 or fewer people. That comparison was for projects of the same size in source lines of code (SLOC), presumably requiring about the same amount of work. For example, at a size of 50,000 SLOC, the large teams expended 99 person-months, the small teams, 19 person-months. The numbers seem hardly believable, and perhaps some of you raised your eyebrows slightly.
In the past, I've put the emphasis on the effort-time tradeoff that the software equation implies:
Functionality (size) = (Process Productivity) (Effort/B)1/3 x (Development Time)4/3
Aided by new data on almost 500 projects from a large corporation, I am putting the emphasis on the great value of small teams. The idea of small work groups is hallowed by time. If ever there was work that is not routine and requires frequent contact, it is software development. What we now bring to the table is metrics. Those metrics establish that the concept of using small work groups in software development is a really beautiful idea. Let us show you the figures.
Small Groups Complete Projects in Less Time
The data obtained came from 491 medium-sized projects with 35,000-95,000 new or modified SLOC. All were information systems completed in the last 3 years. "New or modified" limits the code metric to "Effective SLOC" (ESLOC), that is, the work that was actually done. It excludes reusable components that require little or no new work.
The next step was to stratify the sample projects into 5 team-size groupings. There are 3 features of this stratification to note in particular:
The 3 small groupings took less schedule time than the 2 large groupings. In fact, development time for the three small groupings is about three-quarters of the time for the two large groupings. There is a distinct difference in the schedule time required by groups in the 3-to-7 range as compared to the 9-to-20 as range.
Small Groups Use Fewer Person-Months
As far as the pattern for development effort, the difference is much more marked than in the case of schedule. The 3 small groupings take only about 25% the effort of the 2 large ones -- remember, each grouping is producing about the same amount of system functionality. A distinct difference in the person-months needed to do a comparable amount of work begins to show up when group size exceeds 8 people.
Howard Rubin
Senior Consultant, Cutter Consortium
http://www.cutter.com/consortium/consultants/hrbio.html
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
JUST SAY NO TO SOFTWARE ESTIMATION
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
At a recent conference on software development, I surveyed the 100 or so members of the audience who filled the room to hear about the dynamics of imposed deadlines and the impact on quality and reliability.
"Let's do a quick show of hands," I said. "At the start of a new project, how many of you are given the deadline first?" Hands shot up everywhere. People looked around to see if there was anyone with their hands in their lap. Not one.
"Next question," I continued. "How many of you have at least half the requirements defined at the time you need to start coding?" No hands went up. The crowd laughed a nervous laugh. Misery loves company, but this was scary.
"Last question. As the requirements start building, how many of you know when to say no? As in, 'We can't promise any more than x amount of functionality without putting the deadline in jeopardy.' " Only about five hands went up. I asked them to explain how they knew when to say no. The answers were arbitrary to say the least. It was mostly based on intuition: "It just didn't feel right." No one could say for sure when that line in the sand might be crossed.
I've repeated the experiment at every recent speech, regardless of whether I was speaking on outsourcing, software estimation, risk management, IT benchmarking, quality and testing, or a related subject. The audiences change from city to city, but the answers always seem to be the same.
Based on this feedback from the trenches, here's a bold conclusion: Forget about "traditional" software estimation. Don't bother. After all, how could anyone possibly estimate the schedule to build something they're not sure of? Estimate the schedule? Who cares? I know what the estimate is. The estimate is the deadline, and it's on Internet time!
Abandon the notion of first defining the requirements; then estimating the size of new and changed modules, objects, function points, or code; and translating that into forecasts for time, effort, and the required staff. To do that, we need to know the requirements -- but we don't. And whatever the requirements are initially, they're going to grow in scope anyway. Estimate the staff required? Forget it; it won't matter. Here's the answer on the estimate of the staff size: it's the 20 people we have available. Now, get to work and start coding. Code what? We're not sure yet.
So, what's an overworked project team leader to do? (Run, I say. Run for your life, as fast as you can!) No, seriously. Here's what we know: we know the deadline, and we know how many people we have on hand. We have no choice but to work the problem backward. "How much of this kind of software can we build, with this many people, in this little time?"
When we come up with this number, we grab onto it, hold on tight, and refuse to give in when we are asked to deliver one line of code more than this limit. If the size translates to say, 28 modules, do whatever you have to do to hold your ground and not agree to one module more. It's likely that at least one-third of those will change after you've built the first version anyway, only to be thrown out and reworked. So you'll need the overtime to redo that first version of the code.
Why is it so important to hold your ground? Because from industry metrics research on completed projects, we know that software projects have serious problems when compressed. For example, we've seen defects rise as much as six-fold when deadlines are shortened by, say, 20% through the use of larger development teams. Holding deadlines fixed but letting the scope rise unchecked is the same compression, but from the other direction.
If no additional staff is made available, the project slips "to the right" and is either shipped prematurely with high defects, or the functionality is chopped with a cleaver at the last minute. (We've decided to deliver only the "core functionality." The "core" is whatever works when it's time to cut your losses and ship something, anything, by the looming deadline.) If you have to cut function at the last minute, you might as well know what that limit is ahead of time and design to that size, rather than overpromise and overreach, only to beat a hasty retreat a month before the deadline.
Finally, once the requirements are defined, and that may be as late as halfway through the main build schedule, you can perform an estimate using a comprehensive software estimation or adaptive forecasting model and identify the remaining time and effort that this kind of analysis would forecast. With that in hand, you can then perform a gap analysis. This will identify the amount of time, and the amount of effort, that might be at risk if you had to concede to management or marketing pressures.
To summarize:
1) Don't fight reality; go with the information at hand. You've been given a deadline and a staff size. Work the estimate in reverse, and quantify what you think you have a reasonable chance of building.
2) As the design evolves, hold onto that goal in your mind. As the scope growth reaches your pre-determined mental limit, start polishing up those negotiating skills to hold your ground when the arm twisting and coercion begins. Go home, look in the mirror, and practice saying "No. I don't care if you threaten to fire me."
3) If push comes to shove, tell management, marketing, or the user that relenting to an unrealistic demand would result in attempting to deliver more than is possible, at an unacceptable level of quality. They may win the functionality battle with you, but they stand to lose the reliability war. When deadlines and staff are fixed, and scope grows, there's only one place for the pressure to release -- it will burst in the form of exploding defects.
Michael Mah
Senior Consultant, Business-IT Alignment
Advisory Service
http://www.cutter.com/consortium/consultants/mmbio.html
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
A QUICK CURE FOR PAINFUL DOCUMENT WRITING
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
Software projects require us to write documents. This is especially true on government and outsourced contracts, which often require developers to come up with requirements, design specifications, and/or maintenance documents. But software developers write software for a living, not documents. Developers are neither adept at, nor fond of, writing documents. This lack of skill and desire is a bad combination. Writing a decent document under these circumstances takes too much time. Developers need a way to jump-start the document they're writing, a way to talk and throw out information in any order. Then they need someone else to put the information on paper.
Here's my three-part technique for software project document writing. Start with a document standard such as the MIL-STD-498 for Software Development and Documentation (from the US Department of Defense) or the IEEE's new 12207 standard. Both standards contain expanded outlines for documents called Data Item Descriptions (DIDs). The document standard serves two purposes: It acts as a checklist to remind people what should be in the document, and it organizes the document by showing where to put what information.
Next, cut up the outline of the document and stick the pieces on a wall (or several walls). This permits the developers to see the layout of the entire document. Now, gather the developers -- as a group, not individually. Each person scribbles information on Post-Its and sticks the information on the wall. Grammar and spelling don't count. They also don't have to stick the information in the right section at first, as the Post-Its are easy to move around. What is important is to let the information pour out onto the wall.
The final piece is the recorder, who sits in the back of the group with a PC and enters the information poured out by the developers. When the developers are finished, the recorder touches up the finished document.
This simple technique works well for several reasons. First, everyone can see the entire document. This helps them think and contribute. Second, this method creates synergism. I know you've heard that word used and misused, but it does exist, and it does occur. When several people are thinking about the same problem together, they create better solutions than when working individually. Finally, the people who write software are not writing documents. They're scribbling and throwing information onto a wall. Someone else does the organizing, typing, and writing.
Dwayne Phillips
Dwayne Phillips works as a software and systems engineer for the US government. He recently wrote *The Software Project Manager's Handbook, Principles that Work at Work*, published by the IEEE Computer Society. He can be reached at d.phillips@computer.org.
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
At a recent visit to an IT client, the new QA manager took me aside and said: "JR, here are the metrics I want to measure on a monthly basis. What do you think?" He had attempted to measure efficiency, cost of quality, and defect counts over all projects. (In reality, he hadn't actually measured those things, but those were the titles on the histograms.) I asked him what the reactions to these measurements were. The other managers had no reactions -- the measurements had dropped on the floor with a thud. None of the managers seemed to want to measure things; no one wanted to see his measurements. He had no idea why no one was interested. I asked, "What do you want to accomplish with these measurements?" He wasbstumped. He'd had no idea what he wanted to do with the measurements, he just knew he wanted to collect them.
Measurements are only good if you know what you want to do with them. This IT shop was working on increasing their product capability (the number of products they could release per year), decreasing time to release, and increasing the perceived quality of the products. The measurements the QA manager took were inadequate for those goals.
Decide on your goal
Measurements make no sense without a goal. In many IT groups, increasing product capability (the number of products you can release per year) is a key goal. Additionally, many groups are concerned with how long it takes to release a product, along with how good their estimates were for the project schedule. Some IT groups measure the cost of quality, including defect counts, because their customers are willing to invest in product development but not service or maintenance.
Once you've decided on your goals, you can define appropriate measurements to determine whether or not you've met your goals, and you can understand how well your activities align with the rest of the organization.
Ask questions that will help you define your measurements
My client had some suspicions about why the department's perceived product capability was lower than they had expected. He wanted to answer these questions:
Define measures to answer the questions
Once you've asked your questions, you can decide what to measure to get an answer to those questions. For example:
These aren't the only measurements the group will need, but they are a start to working on the particular issues this IT group wants to address. They can be collected quickly on a weekly basis. They are primarily trend-based data, so there aren't too many pieces of data on one chart, and it's easy to understand the data.
This is an example of the Goal-Question-Metric paradigm. To read more about Goal-Question-Metric, see Vic Basili and D.M. Weiss's "A Methodology for Collecting Valid Software Engineering Data" IEEE Transactions on Software Engineering, Vol. SE-10, no. 6, November 1984).
Johanna Rothman
Senior Consultant, Business-IT Alignment Advisory Service
http://cutter.com/consortium/consultants/jrothbio.html
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
MEASUREMENT IS NO SILVER BULLET
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
When it comes to measurement, the IT industry acts strangely. While other industries depend on measurement, tracking, and control as keys to profitability, the IT industry has yet to embrace measurement on a widespread basis. Even when it recognizes the merits of software measurement, the expectations for it are often unrealistic. Software practitioners want a silver-bullet metric that can answer any development question and do it to several-decimal-point accuracy. Predictably, software measurement doesn't match these expectations and, thus, is usually abandoned before it can deliver a return on investment.
There are a number of things measurement practitioners can do to realign expectations and gain software measurement benefits for their organization:
1. Follow the Goal-Question-Metric approach to software measurement introduced by Victor Basili of the University of Maryland. This approach forces companies to clearly identify their strategic goals for metrics and to pose questions that will track whether or not the goals are being met. Only then are the metrics needed to answer the questions identified and data collection mechanisms put into place. The resulting metrics necessarily depend on the specific goals and questions of the organization. Within the Software Engineering Institute's (SEI) Capability Maturity Model for software are a number of Level-3 key process areas that can form the basis of an organization's goals/questions/metrics. (Note: A new book featuring a foreword by Victor Basili was recently published by McGrawHill: The Goal/Question/Metric Method, by Rini van Solingen and Egon Berghout.)
2. Communicate that there is no silver-bullet software metric, just as there is no silver-bullet accounting metric. Defects, functional size, project duration, and work effort all measure different aspects of software development, and they are not interchangeable. No single measure or single combination metric will satisfy all goals or answer all measurement questions -- one must choose the metric suitable for each specific question.
3. Learn about the available metrics and what they mean before implementing them in an organization. For example, work effort is a function of many variables, including software size, implementation technology, development tools, skills, hardware platforms, degree of reuse, tasks to be done, and many others. As such, no single variable can accurately predict work effort, yet there is often an expectation that a single variable (for example, degree of reuse) can accurately predict effort.
4. Plan a measurement program by using metrics and measures in the manner for which they are intended, and ensure that there is a common understanding of the chosen measures. For example, functional size reflects the size of the software based on its functional user requirements, not the physical size of software. (Physical size of software is often expressed in lines of code.) Together with other variables, it can be used as a technology- independent measure of software size in order to predict effort in software estimation models. However, functional size is not the right measure for predicting data access storage device needs -- these depend on the technology and physical space taken up by the software and the volume of data.
5. Remember that the accuracy of a metric is a function of the least accurate measure it involves. For example, if defects are reported as whole numbers and are used in defect density (defects divided by the software size in function points), the result cannot be decimal-point accurate.
6. Use common sense and statistics to correlate collected data, and question figures that seem out of line. Don't accept data purely at face value without verifying its consistency or accuracy. Many companies collect work effort data on completed projects, but the definition of project work effort can vary widely across different teams (e.g., overtime recorded/not recorded, resources included, work breakdown structure, commencement/finish points, etc). Be careful not to compare data that appears comparable because of common units (e.g., hours) that is actually based on different measurement criteria. For example, two projects may report 100 development hours, but one included overtime and user training hours while the other did not. Although the units are the same, the hours are not comparable.
These are a few of the factors, both human and technical, that can lead to software measurement success. There is a great deal to be gained by tracking and controlling software development through measurement -- if only companies would consider what various measures can provide, rather than seeking a non-existent silver bullet to solve all their measurement needs.
Carol Dekkers
Carol Dekkers is president of Quality Plus Technologies, Inc, which provides professional software measurement training and consulting services as well as IFPUG certified function point training, mentoring, and consulting services. She can be reached at dekkers@qualityplustech.com. Note: additional articles on the subject, including how to set up measurement programs, are available by sending an e-mail to the author or accessing the article request form at http://www.qualityplustech.com
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
LOC FIGURES SHOW DEVELOPMENT PRODUCTIVITY ON THE RISE, FP DATA SHOW NEW LOWS
<><><><><><><><><><><><><><><><><><><><><><><><><><><>
According to data collected for the 1999 Worldwide Benchmark Report by Howard Rubin, figures based on lines-of-code (LOC) production rates show the world and the US in a state of rebound. While US productivity dipped about 50% over the past few years, after showing a slight rebound in 1997, it is back up to 7.7 KLOC per professional per year. However, this is far lower than non-US productivity of 16.7 KLOC per professional per year (which itself is up from 9.9). It is also lower than the worldwide average of 13.6.
But data based on function points (FP) tell a different story. (Note that it is rare for companies to supply both FP and LOC data. Therefore, there should not be any expectation that FP and LOC values would track with each other. In fact, from earlier studies, it appears that organizations that have adopted FP as their primary metric may be at higher levels of process evolution than their LOC peers.) At the worldwide level, FP productivity per professional has gone from 92.5 in 1995 to 41.7 in 1996 to 41.3 in 1997 to 36.9 in this study. At the same time, US figures have gone from 88.17 to 72.7 to a new low of 63.1 in this analysis. The non-US figures appear to have stayed flat at about 30 for the past two years.
Howard Rubin
SURVEY SHOWS LARGE PERCENTAGE OF COMPANIES
WITH SIZABLE APPLICATION DEVELOPMENT BACKLOGS
Over 30% of companies surveyed said they had a 13- to 24-month backlog in application development, according to Chris Pickering, author of the *1998 Survey of Advanced Technology* and Senior Consultant for the Cutter Consortium's Business-IT Alignment Advisory Service. Over 25% of companies said they have a backlog of 7 to 12 months, and over 20% have backlogs of more than 24 months.
The study shows that companies with no backlog are using purchased packages exclusively as their method of system delivery. Currently, 45.8% of the surveyed companies are using packages, while 50.4% are developing applications in-house and 2.4% are using domestic outsourcing.
Purchased packages are also the dominant strategy for legacy systems, with 48.5% of companies employing this method. Other legacy-system strategies include using middleware (17.8%), ongoing use (16.8%), componentization (9.5%), and rewriting (7.4%).
Just over 50% of respondants indicated that software reuse is an active goal for their company or department. However, at this stage, few shops are enjoying any great amount of reuse: 42.3% have achieved less than 10% reuse, 50% have achieved 10% to 25% reuse, and 7.7% have achieved 26% to 50% reuse.
The *Survey of Advanced Technology* gives a detailed look at the current status of advanced technologies at *Fortune* 1000 companies. It is based on a 227-question survey. The report is available from Cutter Information Corp. at http://www.cutter.com/itgroup/reports/sat98.html