IFSM 301 - Strategic Plan Report Part 2

IFSM 301 – Week 4 Citations

(NIST, 2009)

(The six phases of project management, n.d.)

(Waterfall versus Agile Project Management, n.d.)

(Gottesdiener, 2008)

(Value Attainment)

(Potts, 2008)

(Potts, Why You Shouldn't Have an IT Budget, 2008)

(UMUC Faculty)

Bibliography Gottesdiener, E. (2008, March). Good Practices for Developing User Requirements. The Journal

of Defense Software Engineering, 13-17. Retrieved January 25, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543074/View

NIST. (2009, April). The System Development Life Cycle. Retrieved January 25, 2021, from NIST: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543036/View

Potts, C. (2008, November 15). It's Time to Change Your Investment Culture. CIO, 24-26. Retrieved January 25, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543105/View

Potts, C. (2008, May 15). Why You Shouldn't Have an IT Budget. CIO, 74-76. Retrieved January 25, 2021, from https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543106/View

The six phases of project management. (n.d.). Retrieved January 25, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543072/View

UMUC Faculty. (n.d.). Performance Measures. Retrieved January 25, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543077/View

Value Attainment. (n.d.). Retrieved January 25, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543075/View

Waterfall versus Agile Project Management. (n.d.). Retrieved January 25, 2021, from University of Maryland Global Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543073/View

The System Development Life Cycle

For a brief overview of the System Development Life Cycle, the following sections have been directly quoted from the National Institute of Standards and Technology (NIST) publication, The System Development Life Cycle (SDLC). The entire NIST publication is available at: http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf

"The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases.

The System Development Life Cycle

Initiation Phase. During the initiation phase, the organization establishes the need for a system and documents its purpose.

Development/Acquisition Phase. During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. should be identified as well.

Implementation Phase. In the implementation phase, the organization configures and enables system features, tests the functionality of these features, installs or implements the system, and obtains a formal authorization to operate the system. Design reviews and system tests should be performed before placing the system into operation to ensure that it meets all required security specifications. In

addition, if new controls are added to the application or the support system, additional acceptance tests of those new controls must be performed. This approach ensures that new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests should be fully documented, updated as new reviews or tests are performed, and maintained in the organization’s official records.

Operations/Maintenance Phase. In this phase, systems and products are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and software components are added or replaced. The organization should continuously monitor performance of the system to ensure that it is consistent with pre-established user and system requirements, and that needed system modifications are incorporated.

Configuration management (CM) and control activities should be conducted to document any proposed or actual changes to the system. Information systems are in a constant state of evolution with upgrades to hardware, software, firmware, and possible modifications in the surrounding environment. Documenting information system changes and assessing the potential impact of these changes on the system are essential activities to assure continuous monitoring, and prevent problems.

Disposal Phase. In this phase, plans are developed for discarding system information, hardware, and software and making the transition to a new system. The information, hardware, and software may be moved to another system, archived, discarded, or destroyed. If performed improperly, the disposal phase can result in the unauthorized disclosure of sensitive data. When archiving information, organizations should consider the need for and the methods for future retrieval.

Usually, there is no definitive end to a system. Systems normally evolve or transition to the next generation because of changing requirements or improvements in technology.

The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access."

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 1/8

1. The six phases of project management

This chapter provides a sketch of the traditional method of project management. The model that is discussed here forms the basis for all methods of project management. Later chapters go into more depth regarding a model that is particularly appropriate for IT-related projects.

Dividing a project into phases makes it possible to lead it in the best possible direction. Through this organisation into phases, the total work load of a project is divided into smaller components, thus making it easier to monitor. The following paragraphs describe a phasing model that has been useful in practice. It includes six phases:

1. Initiation phase 2. Definition phase 3. Design phase 4. Development phase 5. Implementation phase 6. Follow-up phase

Figure 1: Project management in six phases, with the central theme of each phase

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 2/8

1. The six phases of project management boek

Initiation phase

The initiation phase is the beginning of the project. In this phase, the idea for the project is explored and elaborated. The goal of this phase is to examine the feasibility of the project. In addition, decisions are made concerning who is to carry out the project, which party (or parties) will be involved and whether the project has an adequate base of support among those who are involved.

In this phase, the current or prospective project leader writes a proposal, which contains a description of the above- mentioned matters. Examples of this type of project proposal include business plans and grant applications. The prospective sponsors of the project evaluate the proposal and, upon approval, provide the necessary financing. The project officially begins at the time of approval.

Questions to be answered in the initiation phase include the following:

Why this project? Is it feasible? Who are possible partners in this project? What should the results be? What are the boundaries of this project (what is outside the scope of the project)?

The ability to say no is an important quality in a project leader. Projects tend to expand once people have become excited about them. The underlying thought is, While were at it, we might as well Projects to which people keep adding objectives and projects that keep expanding are nearly certain to go off schedule, and they are unlikely to achieve their original goals.

In the initiation phase, the project partners enter a (temporary) relationship with each other. To prevent the development of false expectations concerning the results of the project, it makes sense to explicitly agree on the type of project that is being started:

a research and development project; a project that will deliver a prototype or ‘proof of concept’; a project that will deliver a working product.

The choice for a particular type of project largely determines its results. For example, a research and development project delivers a report that examines the technological feasibility of an application. A project in which a prototype is developed delivers all of the functionalities of an application, but they need not be suitable for use in a particular context (e.g. by hundreds of users). A project that delivers a working product must also consider matters of maintenance, instructions and the operational management of the application.

Many misunderstandings and conflicts arise because the parties that are involved in a project are not clear on these matters. Customers may expect a working product, while the members of the project team think they are developing a prototype. A sponsor may think that the project will produce a working piece of software, while the members of the project team must first examine whether the idea itself is technically feasible.

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 3/8

1. The six phases of project management

Definition phase

After the project plan (which was developed in the initiation phase) has been approved, the project enters the second phase: the definition phase. In this phase, the requirements that are associated with a project result are specified as clearly as possible. This involves identifying the expectations that all of the involved parties have with regard to the project result. How many files are to be archived? Should the metadata conform to the Data Documentation Initiative format, or will the Dublin Core (DC) format suffice? May files be deposited in their original format, or will only those that conform to the Preferred Standards be accepted? Must the depositor of a dataset ensure that it has been processed adequately in the archive, or is this the responsibility of the archivist? Which guarantees will be made on the results of the project? The list of questions goes on and on.

Figure 2: Expectations of a project (Illustration: Rachèl Harmsen)

It is important to identify the requirements as early in the process as possible. Wijnen (2004) distinguishes several categories of project requirements that can serve as a memory aid:

Preconditions Functional requirements Operational requirements Design limitations

Preconditions form the context within which the project must be conducted. Examples include legislation, working-condition regulations and approval requirements. These requirements cannot be influenced from within the project. Functional requirements are requirements that have to do with the quality of the project result (e.g. how energy-efficient must an

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 4/8

automobile be or how many rooms must a new building have?). Operational requirements involve the use of the project result. For example, after a software project has been realised, the number of malfunctions that occur must be reduced by ninety per cent. Finally, design limitations are requirements that involve the actual realisation of the project. For example, the project cannot involve the use of toxic materials or international partners for whom it is unclear whether they use child labour.

During the definition phase of a project that involved developing a web application for a consortium of large organisations, no agreements were made concerning the browser that would be supported by the application. The consortium assumed that it would be Microsoft Explorer, because it was the browser that everyone used. The programmers created the application in Firefox, because they worked with the browser themselves and because it had a number of functions that were particularly useful during the development. Because most of the websites that are made for Firefox also look good in Explorer, the difference was initially not noticeable. Near the end of the project, however, the customer began to complain that the website didn’t look good. The programmers, who had been opening the site in Firefox, did not understand the complaint.

When the problem of the two browsers became clear, the programmers reacted defensively, Can’t they just install Firefox? After all, it is free. The organisations, however, were bound to the bureaucratic-minded system administrators who, for some possibly justified reason, refused to install Firefox in addition to Explorer. Even if they had wanted to install it, it would have involved a lengthy process, and there would have been extra costs for the time that the system administrators would have to spend on the task. It was ultimately decided that the application would have to be made suitable for Explorer. That involved considerable extra work, whereby the project ran even more behind schedule than it already had, and it was necessary to negotiate the extra costs. It was later discovered that the various organisations were working with different versions of Microsoft Explorer.

It is very important that all parties that are involved in the project are able to collaborate during the definition phase, particularly the end users who will be using the project result. The fact that end users are often not the ones that order the project perhaps explains why they are often ignored. The client, who pays for the project, is indeed invited to collaborate on the requirements during the definition phase. Nonetheless, the project result benefits when its future users are also invited. As a point of departure, it is helpful to make a habit of organising meetings with all concerned parties during the definition phase of a project.

During the development of an educational video game, the users (young people) were involved in the project only at a later stage. When the game was nearly completed, a group of young people was asked to test the game. Their initial assessments appeared mild and friendly. When pressed, however, they admitted that they had actually found the game extremely boring and that they would certainly not play it themselves. Had these young people been involved in the project earlier, the game would probably have been a success. As it stands, the game remains nearly unused on an Internet website.

The result of the definition phase is a list of requirements from the various parties who are involved in the project. Every requirement obviously has a reverse side. The more elaborate the project becomes, the more time and money it will cost. In addition, some requirements may conflict with others. New copy machines are supposed to have less environmental impact; they must also meet requirements for fire safety. The fire-safety regulations require the use of flame-retardant materials, which are less environmentally friendly. As this illustration shows, some requirements must be negotiated.

Ultimately, a list of definitive requirements is developed and presented for the approval of the projects decision-makers. Once the list has been approved, the design phase can begin. At the close of the definition phase, most of the agreements between the customer and the project team have been established. The list of requirements specifies the guidelines that the project must adhere to. The project team is evaluated according to this list. After the definition phase, therefore, the customer can add no new requirements.

A part of a new exhibit in a museum was comprised of a computer installation, the creation of which had been project-based. Because there had been no definition phase in the project, no clear agreements between the museum and those responsible for building the installation had been made. When the computer for the installation broke down halfway through the exhibit, the museum assumed that it would be covered by the projects guarantee. The project team had a different opinion. Negotiations between the directors were necessary in order to arrive at an appropriate solution.

1. The six phases of project management

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 5/8

Design phase

The list of requirements that is developed in the definition phase can be used to make design choices. In the design phase, one or more designs are developed, with which the project result can apparently be achieved. Depending on the subject of the project, the products of the design phase can include dioramas, sketches, flow charts, site trees, HTML screen designs, prototypes, photo impressions and UML schemas. The project supervisors use these designs to choose the definitive design that will be produced in the project. This is followed by the development phase. As in the definition phase, once the design has been chosen, it cannot be changed in a later stage of the project.

Figure 3: Example: Global design for the DANS Architecture Archive

In a young, very informal company, the design department was run by an artist. The term design department was not accurate in this case; it was more a group of designers who were working together. In addition, everyone was much too busy, including the head of the department.

One project involved producing a number of designs, which were quite important to the success of the project. A young designer on the project team created the designs. Although the head of the design department had ultimate responsibility for the designs, he never attended the meetings of the project team when the designs were to be discussed. The project leader always invited him, and sent him e-mails containing his young colleagues sketches, but the e-mails remained unanswered. The project leader and the young designer erroneously assumed that the department head had approved the designs. The implementation phase began. When the project was nearly finished, the result was presented to the department head, who became furious and demanded that it be completely redone. The budget, however, was almost exhausted.

1. The six phases of project management

Development phase

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 6/8

During the development phase, everything that will be needed to implement the project is arranged. Potential suppliers or subcontractors are brought in, a schedule is made, materials and tools are ordered, instructions are given to the personnel and so forth. The development phase is complete when implementation is ready to start. All matters must be clear for the parties that will carry out the implementation.

In some projects, particularly smaller ones, a formal development phase is probably not necessary. The important point is that it must be clear what must be done in the implementation phase, by whom and when.

1. The six phases of project management

Implementation phase

The project takes shape during the implementation phase. This phase involves the construction of the actual project result. Programmers are occupied with encoding, designers are involved in developing graphic material, contractors are building, the actual reorganisation takes place. It is during this phase that the project becomes visible to outsiders, to whom it may appear that the project has just begun. The implementation phase is the doing phase, and it is important to maintain the momentum.

In one project, it had escaped the project teams attention that one of the most important team members was expecting to become a father at any moment and would thereafter be completely unavailable for about a month. When the time came, an external specialist was brought in to take over his work, in order to keep the team from grinding to a halt. Although the team was able to proceed, the external expertise put a considerable dent in the budget.

At the end of the implementation phase, the result is evaluated according to the list of requirements that was created in the definition phase. It is also evaluated according to the designs. For example, tests may be conducted to determine whether the web application does indeed support Explorer 5 and Firefox 1.0 and higher. It may be determined whether the trim on the building has been made according to the agreement, or whether the materials that were used were indeed those that had been specified in the definition phase. This phase is complete when all of the requirements have been met and when the result corresponds to the design.

Those who are involved in a project should keep in mind that it is hardly ever possible to achieve a project result that precisely meets all of the requirements that were originally specified in the definition phase. Unexpected events or advancing insight sometimes require a project team to deviate from the original list of requirements or other design documents during the implementation of the project. This is a potential source of conflict, particularly if an external customer has ordered the project result. In such cases, the customer can appeal to the agreements that were made during the definition phase.

As a rule, the requirements cannot be changed after the end of the definition phase. This also applies to designs: the design may not be changed after the design phase has been completed. Should this nonetheless be necessary (which does sometimes occur), the project leader should ensure that the changes are discussed with those involved (particularly the decision-makers or customers) as soon as possible. It is also important that the changes that have been chosen are well documented, in order to prevent later misunderstandings. More information about the documentation of the project follows later in this handbook.

1. The six phases of project management

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 7/8

Follow up phase

Although it is extremely important, the follow-up phase is often neglected. During this phase, everything is arranged that is necessary to bring the project to a successful completion. Examples of activities in the follow-up phase include writing handbooks, providing instruction and training for users, setting up a help desk, maintaining the result, evaluating the project itself, writing the project report, holding a party to celebrate the result that has been achieved, transferring to the directors and dismantling the project team.

The central question in the follow-up phase concerns when and where the project ends. Project leaders often joke among themselves that the first ninety per cent of a project proceeds quickly and that the final ten per cent can take years. The boundaries of the project should be considered in the beginning of a project, so that the project can be closed in the follow-up phase, once it has reached these boundaries.

It is sometimes unclear for those concerned whether the project result is to be a prototype or a working product. This is particularly common in innovative projects in which the outcome is not certain. Customers may expect to receive a product, while the project team assumes that it is building a prototype. Such situations are particularly likely to manifest themselves in the follow-up phase. Consider the case of a software project to test a very new concept.

There was some anxiety concerning whether any results would be produced at all. The project eventually produced good results. The team delivered a piece of software that worked well, at least within the testing context. The customer, who did not know much about IT, thought that he had received a working product. After all, it had worked on his office computer. The software did indeed work, but when it was installed on the computers of fifty employees, the prototype began to have problems, and it was sometimes instable.

Although the programmers would have been able to repair the software, they had no time, as they were already involved in the next project. Furthermore, they had no interest in patching up something that they considered a trial piece. Several months later, when Microsoft released its Service Pack 2 for Windows, the software completely stopped functioning. The customer was angry that the product once again did not work. Because the customer was important, the project leader tried to persuade the programmers to make a few repairs. The programmers were resistant, however, as repairing the bugs would cause too much disruption in their new project. Furthermore, they perceived the software as a prototype. Making it suitable for large-scale use would require changing the entire architectural structure. They wondered if the stream of complaints from the customer would ever stop.

The motto, Think before you act is at the heart of the six-phase model. Each phase has its own work package. Each work package has its own aspects that should be the focus of concentration. It is therefore unnecessary to continue discussing what is to be made during the implementation phase. If all has gone well, this was already determined in the definition phase and the design phase. For a more detailed description of the six-phase model and the task packets for each phase, see Wijnen (2004) and Kor (2002).

1/25/2021 Six Phases of Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543072/View 8/8

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 1/13

Home Contact

5. Waterfall versus Agile projectmanagement

The six-phase model is a waterfall model. In other words, the phases take place in succession. Just as it is impossible to swim upstream against a waterfall, the pure waterfall method does not allow returning to a phase after it has been completed. During the implementation phase, it is not desirable to decide to adapt the design, thereby bringing implementation to a standstill. For a number of reasons (see e.g. McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton, 2002), the waterfall method is usually less suited to software-development projects.

Software development is a creative process. It is nearly impossible to identify all of the requirements (functionalities) beforehand.

Estimating the amount of time that will be necessary to implement a functionality is quite difficult. It should be possible for all intermediate results to be tested by users throughout the entire trajectory of the project.

Cyclical methods of project management Conditions for cyclical project management

Risks of cyclical project management

5. Waterval versus Agile (cyclisch) project management

Software development is a creative process

To outsiders, software development appears to have more to do with engineering than it does with inventing. It does, however, correspond to inventing in a number of ways. In the process of invention, one never knows in advance precisely what is going to happen.

The designers and programmers who write new software must conceive of solutions for the problems that are set before them. Regardless of the many methods and prescriptions for work, writing programming code remains largely new and

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 2/13

therefore largely uncertain. Programmers can choose their solutions out of millions of possibilities that are written in dozens of programming languages, and which operate according to thousands of hardware configurations and in dozens of software platforms. Although this freedom does offer a number of advantages, it also makes the project more difficult to manage than traditional projects (e.g. construction or building projects).

5. Waterval versus Agile (cyclisch) project management

It is nearly impossible to identify all of the requirements (functionalities) beforehand

The waterfall method prescribes the formulation of requirements as the project result of the definition phase. Ideally, there should be little further deviation from these requirements throughout the rest of the project. The development of software according to the waterfall method requires the investment of considerable time in the beginning of the project in analysing the necessary functionalities (requirements). This leads to a functional design (for more details on functional designs, see [i]). Using the functional design as a guide, the software architect makes a technical design in the design phase. The technical design includes a description of how the desired functionalities should be implemented.

Although this may appear quite straightforward, consider the following situation (example adapted from McConnell, 1996, p. 138). There is a project to produce a new automobile. As an active automobile driver, you are asked to formulate the requirements for an automobile. You consult with other drivers and create an extensive list:

The automobile must accommodate four people. The automobile must have a steering wheel in the front on the drivers left-hand side, a brake pedal, a gas pedal and a hand brake. The automobile must have four wheels. The automobile must have white headlamps and red tail lamps. et cetera (the actual list would obviously be enormous)

Using your list as a guide, the designers develop a new design, which is subsequently built several months later. One day, as you are walking down the street, you see an automobile stopping. You realise that you neglected to include brake lamps in your list! You immediately telephone the engineer of the automobile manufacturer, who nearly explodes in reaction to your call. You maintain that it is only a small change. For the automobile manufacturers, however, it is a disaster. The automobiles that have already been made must be completely disassembled, cables must be stretched from the brake pedals to the rear, the rear of the automobile must be completely re-designed in order to accommodate the brake lamps, the boot hatches that had already been produced would have to be discarded and the list goes on.

While the example above is somewhat absurd, it reflects an almost daily reality in software development. Programmers erroneously assume that the clients, customers or users of the software that is to be developed know precisely what they want Clients erroneously assume that the software builders can make (and adapt) everything in the shortest possible time. This problem is the greatest source of conflict between customers and software builders.

The following anecdote illustrates the fact that there are many conflicts between customers and software suppliers. A beginning entrepreneur wanted to obtain legal insurance for his business. He asked about the possibilities. When the broker asked him to identify the sector in which his business was active, the entrepreneur replied, ‘IT’. Too bad, replied the broker, ‘there are so many lawsuits between IT suppliers and customers that there are no insurance companies that will write legal- insurance policies for IT companies’.

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 3/13

5. Waterval versus Agile (cyclisch) project management

Estimating the amount of time that will be necessary to implement a functionality is quite difficult

The waterfall method assumes a number of phases. In their project plans, project leaders must include estimates of the amount of time (and therefore money) that will be needed for each phase. We have already seen that time estimates are generally difficult for any project, particularly if they must be made in the early stages of a project. For software projects, it is simply impossible. Imagine that it were feasible to compile a qualitatively adequate list of functionalities in the definition phase. In theory, the project team should then be able to provide a reasonable estimate of how much time will be necessary to implement each functionality. In practice, however, there are too many uncertainties to allow a reasonable estimate (e.g. McConnell, 1996):

Once a functionality has been made, it is often discovered that the customer does not need it after all. The hours that were used in implementing this functionality can therefore be regarded as useless. Requirements change during the project. Should the functionality be implemented expensively or inexpensively? There are many possible methods of implementation and realisation. How will the functionality be designed technically? The design largely determines the amount of time that will be needed to make it. How high must the quality of the functionality be? For example, should a web application always remain completely available, or can it be offline for a few hours each year? The time needed to identify and repair errors in software can vary from minutes to weeks. How long will it take to install and integrate the new software into the customers existing systems? The lack of knowledge concerning possible solutions also complicates the estimation of time. Further, it is difficult to estimate how long it will take to acquire the necessary knowledge.

The list above shows that many factors can affect the amount of time that will ultimately prove necessary to implement a new piece of software. Research (McConnell, 1996, p. 168) has shown that the estimates of the time needed to implement a functionality at the beginning of a project varies between four times too little time and four times too much time. This means that the amount of time necessary can turn out to be either four times higher or four times lower than a faulty estimate. These estimates become more accurate as the project progresses. After the functional design has been made, the margin is reduced to twenty-five per cent too much or too little. Only when the functionality is implemented can an estimate be provided with a high level of certainty (see Figure 8).

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 4/13

Figure 8: Accuracy of estimates of time necessary to implement a functionality (Source: McConnell, 1996, p. 168).

Software is never completely free of errors. Even for the well-known packages that are used by many (e.g. Word, Excel, Explorer, OSX, PHP, Flash), there are lists of known bugs available on the Internet. New releases regularly appear on the market, in which software errors have been removed. Customers sometimes expect error-free software. In practice, however, such a goal would make it impossible to complete a piece of software. Moreover, software errors are often not inherent in the software itself.

An educational game was made in Flash. It was agreed that the game would be delivered as a file and that the customer would install it himself on his own server. During the project, the customer requested that a high score feature be included in the game to increase competition between players. This would require a piece of script code in PHP. The game builders made and tested the script code on their own server, which worked in Linux. It worked. The game and script code were delivered to the customer. The customer, however, had a Windows server and, for some reason, the script no longer worked well. The high scores were not saved. The programmer eventually needed a week to resolve the problem. As it turned out, the combination of PHP and Windows does not always work well. The script itself contained absolutely no errors! By using a hack, he was able to get it to work, and everyone was satisfied but who should pay for that extra week of work?

Another software-development project also involved educational software. The problem was that the software worked for the programmers, but it did not work well for the customer. After trying nearly everything, the programmer decided to pay a visit to the customer. As it turned out, the customer was using an old Pentium III system. The slowness of the computer caused the poor performance of the software. The programmers had also tested the software on a Pentium III, but it had worked fine. Further investigation revealed that the customers computer was so slow because it was full of viruses and spyware.

The uncertainty that is illustrated by the examples above does not simplify the writing of project plans. It also complicates agreements between the parties involved. Someone must assume the risks for extra work that must be done. If payment is on an hourly basis, the customer assumes the risk. If a fixed price has been agreed (as in grant-funded projects), the software builder assumes the risk. When more than two parties are involved, it becomes even more complicated. In such a case, who should pay for the extra hours in the project?

Discussions often arise concerning who should be responsible for delays. In many cases, the guilty party is difficult to identify. It is quite possible that none of the parties involved is at fault, as the delay is actually the result of a faulty initial estimate of the number of hours that would be needed. Exceeding the number of project hours and the question of who should pay are frequent sources of conflict in the IT world.

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 5/13

5. Waterval versus Agile (cyclisch) project management

It should be possible for all intermediate results to be tested by users throughout the entire trajectory of the project

It should be possible for all intermediate results to be tested by users throughout the entire trajectory of the project

In the definition phase and the design phase, customers are asked to formulate their requirements as well as possible. This is difficult for two reasons. First, customers have only a limited conception of the possibilities or impossibilities of IT. They do not have a good idea of what is or should be possible or what they should or should not want. Second, customers often have only limited knowledge of their own business processes. Many IT projects involve the computerisation of a customers existing business practices. Even though customers may have worked with the processes for many years, they are often not able to define their own business processes. They can work fine in their own way, but cannot say exactly what that way is. The precise definition of processes is a precondition for making software that will drive computerisation. The complexity for customers thus increases if they must describe existing processes.

The list of requirements that is developed in the definition phase is often incomplete. In the implementation phase, programmers make software according to this incomplete list. When users are confronted with the initial versions of the new software, additional requirements are identified. It looks good, but now can you make it so that I don’t have to keep entering my password? Programmers often complain that customers do not know what they want. Customers appeal to the fact that, because software developers are professionals, they should have determined earlier in the process what the customers wanted.

In a software project that involved the automatic processing of applications for a web-based service, an extensive functional design was made. Long lists of requirements from the customer were compiled. A number of screen designs and flow charts were added, after which the programmers could get started. Probably because the project was under extreme time pressure or perhaps because the customers organisation was rather chaotic, the designers had neglected to include one important component: manual administration. The applications were processed by the software. Because the processing of the applications was to be automatic, the programmers thought that no manual administration would be desired. This requirement also did not appear in the functional design. When the software was delivered for testing, the customer realised that there were exceptions in some of the applications. These applications could not be processed automatically, but would have to be handled manually. The software, however, worked only automatically.

In the waterfall method, the actual project result is tested at the end of the implementation phase. This is late in the development process. The time between the definition phase, design phase and implementation phase sometimes amounts to months or even more than a year. If design errors are discovered in a late stage of the project, it can be expensive or sometimes even impossible to adapt software without beginning an entirely new project. Because we have seen that it is practically impossible to specify all requirements beforehand, a working method that allows the possibility of testing (intermediate) results earlier is desirable.

Comparing a number of prospective software houses, a customer asked the competing parties what was possible. One party was somewhat reserved and doubted whether some of the customers requests would be feasible. The other party had an aggressive sales representative. When the customer asked the sales representative if a particular request would be possible, the sales representative telephoned his programmers. Can we build a functionality that can do X? The programmer, who thought primarily in technical terms, answered that, in principal, anything was possible. Neither the programmer nor the sales representative worried about feasibility in terms of project management (e.g. time, money, complexity, risk).

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 6/13

The sales representatives enthusiasm was more effective than the other parties reserved attitude had been. The customer chose the aggressive sales representatives offer. The newly acquired project subsequently came into the hands of a project leader and a group of programmers. After a time, it became apparent that the project did not fulfil the customers expectations. This had partially to do with the fact that the processes were much more complicated for the customer than they had originally appeared. During a heated discussion between the two parties, the customer referred to the fact that the sales representative had said that functionality X would not be a problem.

5. Waterval versus Agile (cyclisch) project management

Conditions for cyclical project management

To apply cyclical project management, a number of conditions must be met:

1. Users/customers are actively involved. In cyclical project management, the formulation of requirements, design, implementation and testing take place in each

cycle. This means that many decisions must be taken in a cycle. If the software is to provide a good reflection of the wishes of the customer, the customer must participate actively in the project team. Customers must present their wishes as clearly as possible to the programmers and designers. This generally involves weekly (or at least bi-weekly) presence in the project team.

Within a project, customers are involved with determining the desired functionalities and the planning of the cycles. They collaborate on the acceptance tests, approve or reject intermediate results and collaborate on the general direction of the project. The active involvement of the customer also leads to better results in the waterfall method.

2. The team is authorised to take decisions. Within a cycle, the project team must be authorised to do what they think is best. If the project team does not have this

power, the cyclical model of project management will not work. If constant authorisation from superiors is necessary during a cycle, this can lead to stagnation. Moreover, outsiders are often poorly informed about what is going on, because they do not actively participate in the project team; this makes it difficult for them to make sensible decisions.

3. Project result (software) can be broken down into smaller parts. With cyclical project management, parts of the project are performed in a number of cycles. This is possible only if the

software that is to be created is divisible into a number of more or less separate components.

4. The requirements that are imposed by management with regard to the software are primarily global; management does not impose direct, concrete or specific requirements. One of the strengths of cyclical project management is that the customer, designers, programmers and any testers work closely together within the cycles. If there are already specific and concrete requirements at the beginning of a project, this impedes the freedom of the project team to use their better judgment to make design choices. Many requirements on a project are revealed during the process to be in need of adaptation and should therefore not be (too) firmly established in the beginning.

5. The activities are intelligible for the customer. If considerable technical work that is difficult for the customer to understand must take place within a cycle, a risk emerges

that the customer will not be in state to participate well in the team. In such a situation, the customer has very little to contribute to the necessary design choices.

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 7/13

A similar risk arises when the progress is not visible to the customer. For example, much of the work may involve coding, with very little being done on the user interface. It is important that customers have sufficient insight into the substance and progress of a cycle in order to ensure that they are not pushed into the background.

6. It should be possible to take a step backwards. Even in cyclical project management, teams sometimes pursue paths that later prove to have been wrong. In such a case, it

should be possible to take a step backwards. If a new module that is created in a cycle proves inadequate, it must be possible to resume working with the old module. This imposes demands, particularly with regard to the archival and documentation of the project materials. Concurrent Versioning System (CVS) and Subversion are two helpful tools for these tasks (see Appendix 3 for a list of tools).

7. In addition to programming, programmers should be able to communicate with customers, and vice versa. Team members must be in state to think conceptually. Discipline is necessary in order to persevere with the work.

8. The organisation in which the project takes place must also offer sufficient support for this method of working. Systems for time reporting, archiving and scheduling are necessary to support the projects. These registration systems ensure the transparency that is necessary to ensure the adequate distribution of resources across projects and time.

9. Projects should have sufficient priority, team members must be released for projects. Requiring team members to work in too many projects at the same time does not work. If an organisation is insufficiently adjusted to working with projects, the flexibility of cyclical project management is likely to lead to chaos. The waterfall method also benefits from an organisation that is arranged for working with projects (see Wijnen, 2004, p. 111).

The director of a software house, who was more of a visionary than he was a manager, had a brilliant idea nearly every month, and he was continually starting new projects in his company. Older projects were consequently never completely finished, and the employees were sometimes working on as many as five projects at once. The charismatic director had once read a book on rapid application development (RAD) and was quite enthusiastic about it particularly about the aspect of rapid. He posted the basic concepts of RAD over the copier and subsequently assumed that everyone would start working according to these concepts. After all, it was a wonderful method.

5. Waterval versus Agile (cyclisch) project management

Cyclical methods of project management

Because of the issues that have been sketched above, a number of other methods of project management have emerged in recent years. These methods are particularly suited for IT-development projects. Examples of these relatively new streams within project management include DSDM, RUP, eXtreme Programming (XP), RAD and agile project management (McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton, 2002, [ii], [iii])

Although the above-mentioned methods of project management differ according to a number of aspects, they are essentially the same. Because the path toward the final goal of IT projects has proved so uncertain, these methods assume that the goal will be achieved in a number of short cycles. This is the background for the term cyclical project management for these methods.

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 8/13

Figure 9: The activities in a cycle

In cyclical project management, the project goal is pursued in several short, successive consecutive cycles. Each cycle is relatively short, preferably lasting less than one month. Within each cycle, a portion of the project is carried out. Analysis, design, implementation and testing occur within each cycle. This is fundamentally different from the waterfall method, in which these activities all take place within their own separate phases. In addition, the waterfall method prescribes only single moments for definition, design, implementation and testing. In the cyclical method, this occurs many times in sequence.

Various components of the software are implemented during the cycles, which are therefore independent of each other. Evaluation takes place after each cycle is completed. Should advancing insight lead to new of different requirements for the project, the activities of the subsequent cycles are adapted to take them into account.

A cycle begins with the making or adjusting of the schedule. Next, the requirements of the result of the cycle are examined. A design is made, programmed and tested. Evaluation subsequently occurs and, in some methods, the new software is brought into use. Thereafter, the following cycle can begin, in order to carry out the following component of the project. (For a more extensive description of cyclical methods and the differences between the methods, see e.g. Kroll, 2004; Chromatic, 2003; Stapleton 2002.)

The most important advantages of working with the cyclical method are as follows: Higher product quality and improved implementation of functionalities,

More realistic estimates of time and money, Project team is under less pressure,

Higher quality. The previous chapters have shown that it is difficult or impossible to determine of the desired functionalities accurately in the

early stages of a project. In cyclical methods, the desired functionalities are implemented in several short cycles. In each cycle, a small portion of the desired functionality is not only investigated; it is designed, implemented and tested as well. The short succession of design, implementation and testing makes a particularly important contribution to quality improvement. Teams are thereby in state to make adjustments. If a design does not turn out to be good in practice, it becomes obvious during the cycle, thereby allowing adjustment. This way of working also allows customers to request adjustments.

Another reason that cyclical project management leads to better quality is that a cycle involves intensive collaboration between customer, designers and programmers. A multi-disciplinary team jointly conceives of and implements solutions. In the waterfall method, the customer is involved primarily in the beginning, in the formulation of the requirements; thereafter, the designers make a design and then the programmers programme the software. The project leader serves as the link between all of the various parties and must ensure that information that is exchanged is delivered to the right place. In practice, many programmers and designers never see the customer, who re-emerges in the process only after the software has been completed.

Cyclical methods of project management are particularly suited to projects in which the goal that is to be achieved cannot be clearly established beforehand, as in creative projects or research projects. Working in a number of cycles with a multi- disciplinary team in which the end-users are also represented allows the team to discover the real goal of the project and how it can best be achieved. Each cycle contains a point for reflection and an opportunity for adjustment.

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 9/13

In waterfall projects, a goal is formulated beforehand. Reflection on the original goal is less of a possibility. The originally formulated goal is never (fully) achieved, and it is likely that neither the originally formulated goal nor the goal that is achieved is exactly what was originally desired.

Figure 10: Better results are achieved by working in cycles. (Illustration: Rachèl Harmsen)

The last reason why cyclical project techniques generate better results is that the customer performs acceptance tests. Quality is further strengthened by using tests as criteria for well-performing functionality from the very beginning. Programmers must therefore define failing tests (or unit tests) before they write their code. The code is considered acceptable only if it passes the failing test.

Test-oriented work requires programmers to prove that there are no bugs in the new code before they write new code. They do this by developing a test (failing test) that would detect any possible bugs before they begin coding. For example, imagine that a programme must be written for calculating the correct amount of change that you must receive from a candy machine. First, the availability of a function to give change must be tested. This function could be called give_change. A simple test could be made and, when it is performed, it is determined that a give_change function does not yet exist. If the programmer then makes the function but does not yet give it any substance, the test will succeed.

The next step would be to test whether the machine gives the right amount of money back when an item is purchased. Insert sixty cents into the machine and buy an item that costs fifty cents. The test will not succeed, because the function is still empty. The programmer then writes the code. In the give_change function, he writes that the amount of change to be returned is the amount of money that was inserted in the machine, less the price of the chosen candy. The test should now succeed. The process continues in this way; for each component of the software, a test must be devised beforehand (example translated and adapted from Chromatic, 2003, p. 27 ff).

The code is not the only component that must be technically tested; the functionalities must also be tested (i.e. acceptance tests). For these tests, the customer determines the conditions under which the functionalities that are to be built can be accepted, before coding begins (e.g. how quickly a computer must respond to a certain action of a user). The prior specification of the conditions under which the new functionality can be accepted has proven particularly difficult and time- consuming. Nonetheless, the active role of customers in testing is an important determinant in the success of a project.

More realistic estimation of time and money With cyclical project techniques, the functionalities that are to be implemented are not written in stone at the beginning of

the project. The available time is specified. Agreements are made concerning the direction in which the project will proceed, and it is determined in the process what is actually needed, useful and realistic with regard to the software that is to be made. In cyclical projects, the functionalities that are to be implemented are not established as fixed goals, and they thus avoid the risk that the necessary hours, and therefore money, can get entirely out of hand. To prevent such a situation, the available time is used as a starting point, and it is determined during the process what is realistic to expect in that amount of time. Also for this reason, cyclical methods of project management are much friendlier for the project team. The team does what it can do within the specified time, but is not pressured to meet unrealistic schedules or to work within an inadequate budget.

Cyclical methods also facilitate the management of external suppliers. With the waterfall method, a project can become bound to a single supplier until the end of the project, regardless of the performance of that supplier. In the cyclical working

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 10/13

method, is theoretically possible to make new agreements for each cycle or even for each component to be delivered and, if necessary, to change suppliers.

5. Waterval versus Agile (cyclisch) project management

Risks of cyclical project management

Cyclical methods of project management sometimes allow insufficient time to implement the desired functionalities. Because the amount of time is pre-determined, fewer functionalities will probably be made than were originally assumed.

This is indeed a real risk, but it is also inherent in the waterfall method. In the waterfall method, the definition phase includes an extensive analysis of requirements. This analysis could be expected to generate better time planning. This is often not the case in practice, however, for the reasons that are mentioned above. Functionalities are left out in this method as well, as there is not enough money to implement them.

In cyclical methods, requirements are handled pragmatically. For example, the requirements in cycles can be divided according to the MoSCoW rules (Stapleton, 2003):

Must Have: requirements that are essential for the system Should Have: important requirements that people really want

Could Have: requirements that are desirable, but which can be easily omitted Want to Have: but will not have this time round: requirements that can wait until later

Regardless of the fact that there may be no more time for particular functionalities, the DANS project managers agree that cyclical work yields more customer satisfaction than the waterfall method does. At any rate, the expectations are consistently better managed, and the projects deliver results that actually work, even if they are less elaborate than originally hoped.

One frequently mentioned disadvantage of XP is that considerable power comes to rest with the programmers. If they misuse this power, they can hide behind the customers lack of technical knowledge. Preventing this situation requires a project leader who can serve the interests of both the programmers and the customer. Such project leaders assist their customers in choosing and planning the cycles, making the technical background of choices intelligible and providing for administration and reporting.

Finally, another disadvantage of XP is that there is a steep learning curve for programmers, managers and customers with regard to the introduction of the method.

5. Waterval versus Agile (cyclisch) project management

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 11/13

1. The six phases of project management

Initiation phase

Definition phase

Design phase

Development phase

Implementation phase

Follow up phase

2. Managing a project

Time

Money

Quality

Organisation

Information

3. Project reporting

4. The sales representative and the politician

5. Waterval versus Agile (cyclisch) project management

Creative proces

Organizing requirements

Estimating time

Testing intermediate results

Cyclical methods

Conditions for cyclical methods

Risks of cyclical methods

6. DANS software-development method

7. Programme management

Appendix

Appendix 1: Causes delays IT projects

Appendix 2: Roles within a project

Appendix 3: Resources project management

Appendix 4: License handbook

Appendix 5: DANS and makers of handbook

Appendix 6: Action-and-decision list

Appendix 7: Sample Issue log

Appendix 8: Sample Risk log

Appendix 9: Sample meeting report

Appendix 10: Sample project plan

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 12/13

Appendix 11: Sample budget

Appendix 12: Sample financial statement

Resources

Traveling to Amsterdam

Contactform & address

Colophon

Downloads

Terms & Conditions

Privacy

Project Management Handbook

About us

E-learning environment

Project management tools

Projectmanagement-training.net

1/25/2021 Waterfall versus Agile Project Management - IFSM 301 6383 Foundations of Information Systems Management (2212)

https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20543073/View 13/13

March 2008 www.stsc.hill.af.mil 13

Many software developers have a love-hate relationship with requirements. They love having a list of things they need to engineer into the product they are building, but they hate it when the require- ments are unclear, inaccurate, self-contra- dictory, or incomplete. They are right to be concerned.

The price is high for teams that fail to define requirements or that do it poorly. Ill-defined requirements result in require- ments defects, and the consequences of these defects are ugly [1- 6]: • Expensive rework and cost overruns. • A poor quality product. • Late delivery. • Dissatisfied customers. • Exhausted and demoralized team

members. To reduce the risk of software project

failure and the costs associated with defec- tive requirements, project teams must address requirements early in software development and they must define requirements properly.

A Short Review of Requirements Before we get to the nitty-gritty of build- ing requirements models, let us look at some basic requirements concepts. User requirements – the focus of this article – are one of three types of requirements (see Figure 1). The other two types are those related to the mission or business and those that describe the software itself.

Business requirements are statements of the business rationale for the project. These requirements grow out of the vision for the product which, in turn, is driven by mission (or business) goals and objectives. The product’s vision statement articulates a long-term view of what the product will accomplish for its users. It should include a statement of scope to clarify which capabilities are and are not to be provided by the product.

User requirements define the software requirements from the user’s point of

view, describing the tasks users need to accomplish with the product and the qual- ity requirements of the software from the user’s point of view. Users can be broadly defined to include not only the people who access the system but also inanimate users such as hardware devices, databases, and other systems. In the systems pro- duced by most government organizations, user requirements are articulated in their concept of operations document.

Software requirements are detailed descriptions of all the functional and non- functional requirements the software must fulfill to meet business and user needs. Nonfunctional requirements include soft- ware design constraints, external inter- faces, and quality attributes such as per- formance, security, installation ability, availability, safety, reusability, and more [7]. Software requirements, which are docu- mented in a software requirements specifi- cation, establish an agreement between

technical specialists and business man- agers on what the product must do.

The key activities in requirements development are the following: elicitation, analysis, specification, and validation [8]. In elicitation, you identify the sources of requirements and solicit requirements from those sources. Requirements elicita- tion relies on appropriate stakeholder involvement, one of the most critical ele- ments for project success [9]. The goal of requirements analysis is to sufficiently understand and define the requirements so that stakeholders can prioritize and allocate them to software. Specification involves differentiating and documenting functional and nonfunctional require- ments and checking that the requirements are documented unambiguously and com- pletely. Validation examines the require- ments to ensure that they satisfy user’s needs.

Elicitation and analysis are crucial early

Good Practices for Developing User Requirements©

Defining user requirements – the needs of the stakeholders who directly interact with the system – is arguably one of the most dif- ficult challenges in building complex systems. When it comes to defining user requirements for software, it is essential to use models to document and analyze the requirements. This article provides a requirements model roadmap that helps software development teams understand the effective use of requirements models. It also describes good practices for creating and using these models.

Ellen Gottesdiener EBG Consulting

Why the project is being undertaken.

Business Requirements

User Requirements

Software Requirements

What users will be able to do with the product.

What the developers need to build.

Level 1:

Level 2:

Level 3:

Figure 1: Requirements Levels

© 2007 Ellen Gottesdiener.

14 CROSSTALK The Journal of Defense Software Engineering March 2008

activities that require intense stakeholder involvement. To analyze the requirements you are eliciting, a key good practice is to create requirements models (also referred to as analysis models): user requirements repre- sented by text (such as tables, lists, or matrices), diagrams, or a combination of text and graphical material [7]. These models facilitate communications about requirements with your stakeholders.

As you elicit requirements from stake- holders and represent them using require- ments models, you should verify your models to ensure they are internally con- sistent. You also need to prioritize your requirements: With active user involve- ment, you analyze the trade-offs among requirements to establish their relative importance [8].

The User Requirements Model Roadmap Now let us take a closer look at user requirements models. The beauty of the Requirements Model Road Map (Figure 2) is that it shows the relationships between the three types of requirements (business, user, and software) and categorizes the models you can use to represent each type. Each model is designed to answer one of the 5Ws + 1H questions: Who? What? When? Why? How? [7].

(Note that the question Where? pro- vides information mainly about nonfunc- tional requirements. Although these are not user requirements – which depict function- al requirements – analysts asking Where? during analysis will also discover a slice of useful quality attributes such as perfor- mance and usability).

In addition, the user requirements model falls into three categories: scope,

high-level and detailed, and alternative models. Some models (shown in italics in Figure 2) are useful for analyzing the busi- ness process, and others are useful for clar- ifying project scope. Defining stakeholder categories early in elicitation, for example, identifies the people you should involve in requirements modeling. High-level and detailed models, such as use cases, a data model, and business rules, can reveal requirements defects such as errors, omis- sions, and conflicts. Requirements analysts and engineers can substitute alternative models when the engineers better commu- nicate requirements or fit the project cul- ture.

Each requirements model represents information at a different level of abstrac- tion. A model such as a state diagram rep- resents information at a high level of abstraction, whereas detailed textual requirements represent a low level of abstraction. By stepping back from the trees (textual requirements) to look at the forest (a state diagram), the team can dis- cover requirements defects not evident when reviewing textual requirements alone.

Because the requirements models are related, developing one model often leads to deriving another. Examples of one model driving another model are the fol- lowing: • Actors initiate use cases. • Scenarios exemplify instances of use

cases. • A use case acts upon data depicted in

the data model. • A use case is governed by business

rules. • Events trigger use cases.

In this way, you can use various routes to harvest one model from another. This approach helps you develop the models

quickly while at the same time verifying the model’s completeness and correctness.

User Requirements Models Here, in alphabetical order, are brief descriptions of the common user require- ments models shown in the User Requirements Models Road Map.

Activity Diagram An activity diagram is a model that illus- trates the flow of complex use cases using Unified Modeling Language (UML) nota- tion. This model is useful for showing use case steps that have multiple extension steps, and for visualizing use cases.

Actor Map An actor map is a model that shows actor interrelationships. An actor map supple- ments the actor table and can also be used as a starting point for identifying use cases. Actors can be written on index cards (one per index card) or drawn using the UML notation. UML depicts actors in an actor map as stick figures, as boxes (supplement- ed by the notation “<<Actor>>”), or as a combination (e.g., stick figures for human actors, and boxes for nonhuman actors).

Actor Table An actor table is a model that identifies and classifies system users in terms of their roles and responsibilities. This model helps reveal missing system users and identifies functional requirements as user goals (use cases), and also management to clarify job responsibilities.

Business Policies Business policies are guidelines, standards, and regulations that guide or constrain the conduct of a business. Policies are the basis for the decision making and knowledge that are implemented in the software and in manual processes. Whether imposed by an outside agency or from within the company, policies are used to streamline operations, increase customer satisfaction and loyalty, reduce risk, improve revenue, and adhere to legal requirements. This model helps you identify policies allocated to business peo- ple, which in turn allows management to prepare for software implementation by updating procedures, guidelines, training, forms, and other assets needed to enforce the policies. Some policies are also allocat- ed to software for implementation.

Business Rules Business rules are text statements that decompose business policies. Business rules describe what defines, constrains, or enables the software behavior. You use

Business Requirements

1

Why the project is being undertaken.

Business Requirements

User Requirements

Software Requirements

What users will be able to do with the product.

What the developers need to build.

Project Charter

Product Vision

User Requirements

S o ft w ar e R eq u ir em en ts

D es ig n an d D ev el o p m en t

Scope High-Level

and Detailed

Alternative Models

* Business Model

Stakeholder Categories

Actor Table Optional: Actor Map, Dialog Map

Prototypes Dialog Hierarchies

Personas Who?

Relationship Map* Glossary

Context Diagram Data Model

Class Model Data Dictionary Data Tables

What?

Event-Response Table

State Diagrams State-Data MatrixWhen?

Business Policies

Business Rules Decision Tables Decision TreesWhy?

Process Map* Use Cases

Optional: Use Case Map,

Use Case Packages

Scenarios, Stories Activity Diagrams, Data Flow Diagrams

How?

Level 1:

Level 2:

Level 3:

Figure 2: User Requirements Model Roadmap

The Beginning

Good Practices for Developing User Requirements

March 2008 www.stsc.hill.af.mil 15

business rules to specify the controls that govern user requirements and to clarify which rules should be enforced in software and which will be allocated to business people. Because business rules require data, defining the rules will uncover need- ed data. User requirements depend on the complete and correct enforcement of business rules.

Class Model A class model is a diagram that shows the classes to be used in a system. A class is the generic definition of a collection of simi- lar objects (persons, places, events, and physical artifacts). You use a class model in projects employing object-oriented software development methods, tools, or databases.

Context Diagram A context diagram is a model that shows the system in its environment with the external entities (people and systems) that provide and receive information or mate- rials to and from the system. This model helps stakeholders to quickly and simply define the project’s scope and to focus on what the system needs as inputs and pro- vides as outputs. A context diagram helps the team derive requirements models (such as actors, use cases, and data model information) and can reveal possible scope creep problems as new external entities are added.

Data Dictionary A data dictionary is a model that provides a description of the data attributes and structures used in a system. This model is a central place for defining each data ele- ment and describing its data type, length, and format. Some project teams use data modeling tools that provide data dictio- nary capabilities.

Data Flow Diagram (DFD) A DFD is a model that shows related inputs, processes, and outputs for process- es that respond to external or temporal events. Unlike use cases (which are orient- ed toward actor goals), DFDs focus on the data that goes in and out of each process, taking an internal view of how the system handles events.

Data Model A data model shows the informational needs of a system by illustrating the logi- cal structure of data independent of the data design or data storage mechanism. You use a data model to identify, summa- rize, and formalize the data attributes and structures needed to satisfy functional

requirements and to create an easy-to- maintain database. Data models help to simplify design and programming and help identify external data entities (other systems that supply data to the software).

Data Table A data table is a model in the form of a table that contains sample data to elicit and validate a data model or data dictio- nary. Each row represents a set of occur- rences in an entity, and each column rep- resents sample attributes.

Decision Table A decision table is a model that specifies complex business rules concisely in an easy-to-read tabular format. A decision table documents all the possible condi- tions and actions that need to be account- ed for in business rules. Conditions are fac- tors, data attributes, or sets of attributes and are equivalent to the left side of atom- ic business rules. Actions are conclusions, decisions, or tasks and are equivalent to the right side of atomic business rules. Factors that must be evaluated form the top rows of the table. Actions make up the bottom rows of the table.

Decision Tree A graphical alternative to a decision table, a decision tree presents conditions and actions in sequence. Each condition is graphed with a decision symbol represent- ing yes or no (or a true or false conclusion). Branches to additional conditions are drawn left to right. Actions are drawn inside rectangles to the right of the branch to which they apply.

Dialog Hierarchy A dialog hierarchy is a model that shows the dialogs in a system (or Web page) as a hierarchy. It does not show transitions.

Dialog Map A dialog map is a diagram that illustrates the architecture of a system’s user inter- face. It shows the visual elements that users manipulate to step through tasks when interacting with the system. Dialog maps can be used to uncover missing or erroneous use case paths and to validate use cases, scenarios, or both in require- ments walkthroughs with users.

Event-Response Table An event-response table model identifies each event (an input stimulus that triggers the system to carry out a function) and the event responses resulting from those functions. An event-response table defines the conditions to which the system must

respond, thereby defining the functional requirements at a scope level. (Each event requires a predictable response from the system.) This model can also reveal needs for external database access or file feeds.

Glossary The glossary is a list of definitions of busi- ness terms and concepts relevant to the software being developed or enhanced.

Persona The persona is a description of an actor as a fictitious system user or archetype. You describe each persona as if he or she is a real person with personality, family, work background, preferences, behavior patterns, and personal attitudes. The focus is on behavior patterns rather than job descriptions. Each persona description is written as a narrative flow of the person’s day with added details about personality. Four or five personas represent the roles that use the system most often or are most important to the functional require- ments.

Process Map A process map is a diagram that shows the sequence of steps, inputs, and outputs needed to handle a business process across multiple functions, organizations, or job roles. This model helps you identi- fy the processes that are allocated to the business (manual processes) and those that will be allocated to software.

Prototype A prototype is a partial or preliminary ver- sion of a system created to explore or val- idate requirements. Exploratory proto- types can be mock-ups using paper, white- boards, or software tools.

Relationship Map A relationship map is a diagram that shows the information and products that are exchanged among external customers, suppliers, and key functions in the organi- zation. This model helps you understand the organizational context of the project by identifying affected business functions and their inputs and outputs.

Scenario A scenario is a description of a specific occurrence of a path through a use case (i.e., a use case instance). Example: A cus- tomer calls to reschedule a job, adding another service and requesting a repeat customer discount.

Stakeholder Categories Stakeholder categories are structured

arrangements of groups or individuals who have a vested interest in the product being developed. You use this model to understand who has an interest in or who has influence on the product, who will use the software and its outputs, and who the product will affect in some way. These groups and individuals will need to be kept informed about requirements progress, conflicts, changes, and priorities.

State-Data Matrix A state-data matrix model shows attribut- es that are added or changed during a state change. Each attribute is identified in the data model and data dictionary.

State Diagram A state diagram is a visual representation of the life cycle of a data entity. Events trigger changes in data, resulting in a new state for that entity. Each state is a defined condition of an entity, a hardware compo- nent, or the entire system that requires data, rules, and actions. A state diagram can also show actions that occur in response to state changes. You use a state diagram to understand how events affect data and to identify missing requirements such as events, business rules, data attrib- utes, and use case steps.

Story A story is a text description of a path through a use case that users typically doc- ument. Stories replace use cases and sce- narios when you are planning releases for agile projects. Stories are essentially detailed scenarios, but each story is judged by developers to require less than two weeks to develop. When combined with acceptance tests, stories are roughly equiv- alent to use cases.

Use Case The use case describes in abstract terms how actors use the system to accomplish goals. Each use case is a logical piece of user functionality that can be initiated by an actor and described from the actor’s point of view in a technology-neutral manner. Use cases summarize a set of related sce-

narios. The purpose of use cases is to reveal functional requirements by clarifying what users need to accomplish when inter- acting with the system. Use cases are a nat- ural way to organize functional require- ments and can be easier for users to under- stand and verify than textual functional requirements statements.

Use Case Map The use case map is a model that illus- trates the work flow of use cases. Each use case map represents a set of highly cohesive use cases sharing the same data, often triggered by the same events or ini- tiated by the same actor.

Use Case Package The use case package is a logical, cohesive group of use cases that represents higher level system functionality. You create a use case package by combining use case maps or grouping use cases. Most systems will have multiple packages. You can use a UML file folder notation to show each package, and you can name each package according to its functionality.

Good Practices for Modeling User Requirements Following good requirements modeling practices (see Good Practices for Modeling User Requirements, Table 1) is the key to successful development of user require- ments. These practices accelerate model- ing, engage stakeholders, and give you high-quality requirements – ones that are correct, complete, clear, consistent, and relevant.

The first good practice is to represent and agree on the project’s scope early in requirements elicitation. Why? It has to do with scope creep – the unrestrained expansion of requirements as the project proceeds. Scope creep is one of the great- est risks in software development [6]. A clear definition of product scope narrows the project’s focus to enable better plan- ning, better use of time, and better use of resources. Moreover, scope-level models establish a common language that team members can use to communicate about

the requirements and help to articulate the boundary between what is in and what is not in scope for the product.

Another good practice, as mentioned earlier, is to document your product using multiple user requirements models. Each model describes one aspect of a problem the product will address. Thus, no single model can describe all the requirements. Furthermore, elements of one model often link to elements of another, so one model can be used to uncover related or missing elements in another model.

It is also good to use both text and graphics to represent user needs. Multiple representations tap into different modes of human thinking. Some people think more precisely with words, and others understand concepts more quickly via dia- grams. Using both types of representa- tions leverages these different thinking modes. In addition, mixing text and graphics makes requirements develop- ment more interesting and engaging. It provides variety and permits stakeholders to understand their requirements from more than one angle.

You should also select models that fit the domain of your product. That is because some models are better suited to communicate requirements for certain domains. For example, When models (such as an event-response table and a state machine diagram) are well suited to dynamic domains – those that respond to continually changing events to store data and act on it based on its state at a point.

Another well-known good practice is to develop your requirements iteratively. Each iteration is a self-contained mini- project in which you undertake a set of activities – elicitation, analysis, specifica- tion, and validation – resulting in a subset of requirements. The rationale for this practice is that user requirements seldom remain unchanged for a long period. On teams using agile methods, each iteration also incorporates the work needed to deliver the working software that satisfies those requirements. In some domains, requirements change faster than the sys- tem or subsystem can be developed. In addition, the cost of implementing changes increases dramatically as the pro- ject proceeds. Developing requirements in an evolving manner is essential in reducing these risks.

You can also use requirements models to identify requirements defects. The interconnections among the models help to expose any inconsistencies in related models. This self-checking accelerates the team’s ability to uncover missing, erro- neous, vague, or conflicting requirements.

The Beginning

16 CROSSTALK The Journal of Defense Software Engineering March 2008

1. Define, represent, and agree on the project’s scope early in requirements elicitation.

2. Document your product using multiple user requirements models. 3. Select models that fit the domain of your system. 4. Develop requirements models iteratively. 5. Use requirements models to identify requirements defects. 6. Use models to communicate: Create simple, readable diagrams focused less

on beauty and more on understanding. 7. Conduct retrospectives as you iterate through requirements development.

Table 1: Summary: Good Practices for Modeling User Requirements

Good Practices for Developing User Requirements

March 2008 www.stsc.hill.af.mil 17

When you are creating graphical mod- els, it is crucial to create simple, readable diagrams. The benefit of diagrams is that they give you a way to quickly communi- cate complex, controversial, or unclear requirements. Thus, you should avoid complex, hard-to-read diagrams. Draw diagrams manually to begin with or use an easy-to-learn drawing tool. Keep them simple and easy to read. Focus on main- taining accuracy and exposing unclear or incorrect requirements – not beauty or completeness.

The final good practice I want to men- tion applies whether or not you are using modeling: I always tell my clients to con- duct short retrospectives at the end of each requirements iteration. A retrospective is a special meeting in which the team explores what works, what does not work, what can be learned from the just com- pleted iteration, and what ways to adapt their processes and techniques before starting another iteration [10, 11]. Retrospectives allow for early learning and correction and may be your team’s most powerful tool for process improvement.

On Your Way Software development teams enjoy access to a world of tools and technologies, but building truly successful software still depends on team members gaining a deep understanding of user needs. When your team is developing a software product, you will save time, money, and frustration by using appropriate models to describe and analyze the product’s user require- ments.u

References 1. Reifer, Donald J. “Profiles of Level 5

CMMI Organizations.” CrossTalk Jan. 2007.

2. Schwaber, Carey. “The Root of the Problem: Poor Requirements.” IT View Research Document. Forrester Research, 2006

3. Dabney, James B., and Gary Barber. “Direct Return on Investment of Software Independent Verification and Validation: Methodology and Initial Case Studies.” Assurance Technology Symposium, June 2003 <http:// sarpresults.ivv.nasa.gov/ViewResearch /24.jsp>.

4. Hooks, Ivy F., and Kristina A. Farry. Customer-Centered Products: Creat- ing Successful Products Through Smart Requirements Management. New York: Amacom, 2001.

5. Nelson, Mike, James Clark, and Martha Ann Spurlock. “Curing the Software Requirements and Cost

Estimating Blues.” The Defense Acquisition University Program Manager Magazine Nov.-Dec. 1999.

6. Jones, Capers. Patterns of Software Systems Failure and Success. Boston, MA: Thomson Computer Press, 1996.

7. Gottesdiener, Ellen. Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. Methuen, MA: Goal/QPC, 2005.

8. Institute of Electrical & Electronics Engineers (IEEE). “IEEE Software Engineering Body of Knowledge.” IEEE Computer Society, 2004 <www.swebok.org>.

9. Standish Group International. “CHAOS Chronicles.” Standish Group International, 2003.

10. Kerth, Norman L. “Project Retro- spectives: A Handbook for Team Reviews.” New York: Dorset House, 2001.

11. Gottesdiener, Ellen. “Team Retro- spectives for Better Iteration Assess- ment.” The Rational Edge Apr. 2003 <http://ebgconsulting.com/Pubs/ Articles/TeamRetrospectives-Gottes diener.pdf>.

About the Author

Ellen Gottesdiener, principal consultant, EBG Consulting, helps get the right requirements so projects start smart and deliver the right product

at the right time. Her book, “Require- ments by Collaboration: Workshops for Defining Needs” describes how to use multiple models to elicit requirements in collaborative workshops, and “The Software Requirements Memory Jogger” describes essentials for requirements development and management. In addi- tion to providing training, eLearning and consulting services, she speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis Business Analysis Body of Knowledge.

EBG Consulting, Inc. 1424 Ironwood DR West Carmel, IN 46033 Phone: (317) 844-3747 E-mail: [email protected]

Get Your Free Subscription

Fill out and send us this form.

517 SMXS/MXDEA

6022 Fir Ave

Bldg 1238

Hill AFB, UT 84056-5820

Fax: (801) 777-8069 DSN: 777-8069

Phone: (801) 775-5555 DSN: 775-5555

Or request online at www.stsc.hill.af.mil

NAME:________________________________________________________________________

RANK/GRADE:_____________________________________________________

POSITION/TITLE:__________________________________________________

ORGANIZATION:_____________________________________________________

ADDRESS:________________________________________________________________

________________________________________________________________

BASE/CITY:____________________________________________________________

STATE:___________________________ZIP:___________________________________

PHONE:(_____)_______________________________________________________

FAX:(_____)_____________________________________________________________

E-MAIL:__________________________________________________________________

CHECK BOX(ES) TO REQUEST BACK ISSUES:

DEC2006 c REQUIREMENTS ENG.

JAN2007 c PUBLISHER’S CHOICE

FEB2007 c CMMI

MAR2007 c SOFTWARE SECURITY

APR2007 c AGILE DEVELOPMENT

MAY2007 c SOFTWARE ACQUISITION

JUNE2007 c COTS INTEGRATION

JULY2007 c NET-CENTRICITY

AUG2007 c STORIES OF CHANGE

SEPT2007 c SERVICE-ORIENTED ARCH.

OCT2007 c SYSTEMS ENGINEERING

NOV2007 c WORKING AS A TEAM

DEC2007 c SOFTWARE SUSTAINMENT

JAN2008 c TRAINING AND EDUCATION

FEB2008 c SMALL PROJECTS, BIG ISSUES

To Request Back Issues on Topics Not Listed Above, Please Contact <stsc. [email protected]>.

Value Attainment

"Companies invest in IT to achieve a business result. Although many organizations implicitly include this activity as part of project implementation, I call it out separately here because it is a different activity. In fact, many IT organizations do not even attempt to ascertain whether the desired business result has been achieved. In these organizations, determining whether or not a system initiative achieves the expected results is either relegated to the business, or it is not done at all. Failing to assert the value of past IT investments almost certainly dooms a company to fail to achieve these results. Just as purchasing a system is insufficient to implementing it, completing a project does not guarantee that the business value expected is achieved. Only if a company monitors the value from its IT investments will it know if that value has been attained. More important, monitoring will help a firm determine what adjustments are necessary to achieve the expected value from an investment. Failing to monitor value attainment also sets the stage for companies to improperly set the investment level for IT. If the perception is that IT investments have not yielded results, the company will underinvest in IT in the future. If the perception is that IT investments have achieved results when in fact they have not, the firm will continue wasteful spending. Neither is desirable for a CIO. One of the best examples in my career of why value attainment is so important was an international travel and expense solution I implemented at a major Fortune 500 company. The desired business result of this solution was the reduction in overhead from processing paper expense reports. The solution was implemented exactly to the business requirements on time and on budget. At the end of the project, the project team and the business were ready to pat themselves on the back and move on. However, I required that the team assess whether the value proposition for the project had been achieved. They were shocked to learn that not only had no operational savings from the project been realized, but the additional overhead from using the new system had actually created additional cost! While the finance organization was spending less time processing paperwork, there had been no staffing reductions as a result of the system. Moreover, the employees using the system spent twice as much time filling out the online forms as they did the paper forms. What had seemed like success was in fact a total failure, which had resulted from an overemphasis on the requirements to the exclusion of the business results for which the project had been funded. However, by assessing whether the business results had been attained before ending the project, we were able to make adjustments to the system to reduce the overhead on employees and provide better reporting to the finance organization that enabled it to achieve its staffing targets. In short, by monitoring value attainment, we ensured that the value from the project was attained. A successful process for value attainment is a subject worthy of its own book. However, in its most basic form, it requires three things:

1. An intimate understanding of the business

2. Proper oversight of projects

3. A commitment by both IT and the business to manage to results, not just requirements

As such, it is a crucial element in aligning the IT organization with the business. The IT organization that leads the value attainment process will find itself asking the question: ‘‘What can be accomplished with an additional 10 percent?’’ rather than ‘How can you cut an additional 10 percent?'’’

Campos, T. (2011). Strategic alignment. In D. Lane (Ed.), The Chief Information Officer's Body of Knowledge: People, Process, and Technology (pp. 81-82). Hoboken, NJ: John Wiley & Sons, Inc.

Applied Insight CHRIS POTTS

It's Time to Change Your nvestment Culture

CIOs are well-positioned to help companies take better advantage of all investments, not just IT

uccess in exploiting technology is rooted in a company's

investment culture. The more mature this culture, the more value

everyone will see from investing in change and IT. The opposite is

also true. Executives that are unhappy or unsure about the value

coming from the changes they are investing in need some cultural leader-

ship. As the old IT strategy evolves into the corporate strategy for investing in

change, up steps the CIO. In response to long-standing concerns about

the costs and value of IT. IT service delivery has matured. Supply-side IT culture is now much more mature than that of many of its customers. Ongo- ing innovations and improvements in the design and delivery of IT tools are often unmatched by the exploitation of those tools once delivered. As an illustration, Gartner recently noted about business intelligence technology: "after years of investment and inipiementation...no more than 20 percent of business users actually use BI proactively." In such instances, the delivery of IT has not heen integral to a successful investment in business change.

Now it's time for CIOs and their executive col- leagues to switch focus, from culture change in IT to the investment culture of the business as a whole.

For companies that succeed at integrating IT with all business investment decisions, the benefits will extend heyond better IT decision making.

Culturally, many companies still misunderstand deeply the linkages between spending money on IT and creating value by investing in change. Such misunderstandings reach all the way to the top. As the Financial Times astutely observed back in 2005, "Boards have clamped down on IT spending because of dissatisfaction about the results, as investments fail to deliver on their promise." Now, as boards face up to today s eco- nomic challenges, there's every indication they are doing the same again. Yet the business changes that mean investments deliver on their promise happen outside of IT. and a clampdown on IT spending does not make those changes any more

24 NOVEMBER 15, 2 0 0 8 | www.cio.com

.pplied Insight CHRIS POTTS

likely to happen.

Change the Business Culture Acomviany'sculturc is powerful, deep-rooted and jjotentially ruthless. For those who chal- lenge an incumbent culture, the battle scars are many, but the outcome can be worth it. There may be nothing more rewarding for a corporate strateg:ist than seeing people release themselves from cultural constraints and achieve more of tlieir true poten- tial both as individuals and as a business.

Most CIOs have already taken one or more IT depart- ments through a culture change. They are equipped better than many for leading culture change in the wider company, but need to be aware of some differences. Culture change in IT has typically focused on service delivery and business operations, whereas the CIO's role is evolving into invest- ment management and corporate strategy. It is also very dif- ferent to lead culture change in your own department with like-minded external suppliers, than it is collaborating in an interdependent network of culture changes across the business as a whole.

It is essential that a CIO, leading a strategy about invest- ing in change, coordinates her tactics with other executives. There's a high risk of unplanned conflict between them, and if it erupts, they will end up battling each other while the cor- porate culture watches, metaphorically, from the sidelines. Also, the executive-level culture may need to cbange first, and collaboration is one of the CIO's options for achieving this.

Thankfully, the CIO's strategy only needs to work on some dimensions of the corporate investment culture, not change

the entire culture. So the CIO's first step is to pinpoint the specific cultural dimensions that her strategy needs to change or preserve. For example, what is

the predominant focus of the company's innovations? What drives the current strategy for investing in change? How are investment initiatives targeted? How prominently does the exploitation of changes figure in the culture? I use a one-page diagnosis exercise with 10 such questions and four possible answers to each one. After no more than an hour, we have a view of the investment culture that can be verified and then used to set tactics.

Where Companies Need Fixing Having worked tbis through with many organizations, some patterns are apparent. It's common for a company to consider carefully the value of an investment (whether in IT or some-

It seems rare to ñnd a company where the exploitation of change is center stage. The main focus is on making changes happen on time, to scope and within budget.

More About Investment Culture

Chns Potts writes about TOOLS FOR

LEADING BUSINESS CHANGE at www

ciacom

thing else) at the beginning of the process, in a business case. then let the focus slip thereafter. Even companies with ben- efits realization in place at the end of the investment process often lose focus on value between investment approval and implementation. By the time changes are delivered, there's no guarantee that the original benefits can still be achieved, or even that the change is still worth making.

Another striking feature of many companies' cultures is the assumption, evident both in the investment portfolio and individual initiatives, that every change will deliver the value in its proposal. Yet a proportion of investments are bound to fail. This can be because assumptions in the pro- posal him out to be flawed, the business context has changed, or it becomes clear that the company will not know how to exploit thechanges once they have been made. In some com- panies, it can be taboo for a project manager to report that a change is not going to deliver its expected value after all, and recommend stopping the investment.

At the moment it seems rare to find a company where the exploitation of change is center stage. It is a support act at best, witb the main focus on making changes happen on time, to scope and within budget. While many companies have ben- efits realization as the final stage in their investment process, especially when IT is involved, few have made the exploitation of change a systemic part of managing business as usual. Only when they do will they see the true value of the investments they are making, whether these involve IT or not.

The next level contribution of the CIO beckons. Having changed the culture in IT. it's now time to develop the cor- porate culture to fully exploit the technology and everything else that the company invests in. It won't be easy. The exist- ing culture will drive you to behave in a way that preserves the status quo, or even take you down. But with the right strategy, you can change it for the better. And then you will be ready to move on and do it all again. Or something even more rewarding. QEl

Chris Potts is corporate IT strategist and CIO futur-

ist with consultancy Dominic Barrow, He is the

author of FrulTion: Creating the Ultimate Corpo-

rate Strategy for /nformation Technology. Reach

him at [email protected]. To comment

on this article goto www.cio.com/article/457917.

26 NOVEMBER 15, 2008 | www.cio.com

Cost Estimation

“In the assessment phase, estimators analyze the project to be estimated. Time pressure typically constrains their ability to understand the scope of the task, so a focus on ramping up the estimators’ knowledge of the business problem is essential. The general approach is to model the solution, identify the components, and then estimate their size and complexity. Finally, tasks that are not strictly mapped to components are added. The essential point is that effort is not estimated at this point—just size and complexity. Here we introduce the first bias reduction mechanism: The sizing should be performed independently by more than one person. If the enterprise has never developed a system like this before, cost estimation will be a problem. Looking at similar solutions implemented by competitors can help with understanding the complexity (e.g., there are many details in the shopping cart checkout process: change quantities, cancel item, shipping options, calculating shipping costs, etc.).”

Murthy, S. (2011). Project cost estimation. In D. Lane (Ed.), The Chief Information Officer's Body of Knowledge: People, Process, and Technology (p. 175). Hoboken, NJ: John Wiley & Sons, Inc.

Think Tank CHRIS POTTS

Why You Shouldn’t Have an IT Budget To get the most from your IT investments, consider not what is in your budget, but what you’re spending to reach business goals

ne of the many diamonds of wisdom that come from

working with people running companies is that a corporate strat-

egy needs a constraint or two.

While the strategy sets the ambition and context for business deci-

sions, constraints drive us to make them. Two things, however, are vital: A constraint

must be genuine, and people must use it to execute the strategy, not undermine it.

With talk of global economic challenges in the air, it’s a good time to reflect on what we’ve learned about the value of IT spending constraints to the success of the CIO’s strategy. Some hatch batten- ing-down seems inevitable, so let’s turn this to our advantage. Even if current economic concerns turn out to be misplaced, we can make sure the strategy wins either way.

What to remember about constraining IT costs? First, a CIO’s departmental budget is rarely the same as a company’s total IT spending. Constrain- ing the IT budget is no guarantee of constraining overall IT costs because there are almost always IT expenditures in business unit budgets.

Second, constraining IT costs in isolation from business decisions breaks the first principle of IT investment (technology, on its own, delivers no

value). IT budget constraints potentially impact all who use IT to create business value, and all the related business decisions. So let’s understand, and utilize, the business causes of IT costs and the busi- ness impacts of constraining them in order to define how much to spend on IT.

Define the IT Budget Rachael is the CIO of a major transportation com- pany, with a staff of 400. Her IT budget is $245 mil- lion, 17 percent more than last year. When times are tough, that seems wrong. Most departmental budgets are likely to be frozen or cut. However, her executive colleagues know what is causing the increase. Rachael’s budget is a variable proportion of the company’s total IT spending, and she consis- tently reduces her like-for-like budget (i.e., exclud-

O

74 m ay 1 5 , 2 0 0 8 | www.cio.com

MAY15 COL THINK.indd 74 5/6/08 12:54:30 PM

ing the incremental impacts of new projects and of business volume growth).

Rachael leads the corporate strategy for IT. Its promise is that the company will cre- ate maximum value from all its investments involving IT. The IT numbers that most con- cern her are the company’s total IT costs. The two numbers she wants to explore are total cash spending on IT and the total cost of IT to profit and loss (P&L). Cash spending is money that goes out the door; cost to P&L is how much IT costs the profit of each business unit and of the company. The two numbers are different and are usually managed by different people.

Elements of both appear in corporate, business unit and project budgets. Rachael’s strategy relies on transparency of both the total numbers and the business decisions behind them. The last thing that she needs is for people to hide IT costs, call them something else, or call non-IT costs “IT.” Such behaviors obscure the truth and undermine the tactics for using IT costs to influence business decisions.

Rachael is transparent with her colleagues about her department’s costs, their underlying causes and what those costs pay for, so they are equally frank with her about their own IT-related costs. They are all confident that they are working with the bona fide total IT numbers within an immaterial margin for error. As a result, Rachael can estimate that the company will spend $316 million this year on IT, 27

percent less than last year. While her departmental budget is increasing, total IT spending is declining. How- ever, Rachael also has to tell her colleagues that IT’s total

cost the company’s P&L will rise 15 percent to $285 million. What are the main causes of the movements in these num-

bers, and what can be done to reduce how much is spent on IT? This is where exploring IT costs in isolation has to stop and the business context for those numbers must begin.

Rachael explains that total cash spending on IT is expected to decline this year because the company plans to invest less in business projects, and a lower proportion of those projects’ total business investment will be spent on IT. However, she says, the actual total may be different from current provisions because many projects have yet to be initiated or conceived.

Cut Spending the Right Way If the executives want to reduce total cash spending on IT, what options do they have? There will be some scope to prune total operational expenditure on IT. However, this will be pay- ing for services used by the company’s employees and cus- tomers to create value within the organization and beyond.

These expenses are also covered by contracts with suppliers and IT employees. The main room for maneuver likely lies in business projects involving IT. Now, with everyone looking at the IT numbers, they might be tempted to prioritize the IT costs within projects to meet a new, lower, IT total. This is the right process but it is looking at the wrong numbers.

The cash that executives plan to spend on IT is one ele- ment of the total project investment necessary to deliver the promised benefits. If the executives want to prioritize investments in projects involving IT, they need to consider the entire project, not just the IT pieces. They can choose not to invest in projects that promise little bang for the business buck. A better process is to explore how to achieve the same bang by spending less–even nothing–by exploiting existing systems. When they’ve finished, total IT spending within projects may be less or the same, but the company will have the most productive portfolio of projects involving IT given the cash constraints.

Turning to the total IT costs to P&L, again, where is the room for maneuver? In Rachael’s company these are rising while total cash spending on IT is falling. This is because the costs to P&L are primarily caused by previous years’ proj- ects, not this year’s. Capital investments in IT cause depre- ciation charges to P&L for years ahead, while many projects involving IT cause permanent increases in the operational costs for IT services. The best time to start constraining this year’s IT costs to P&L was last year and before!

Constraining future IT costs to P&L needs to be an inte- gral part of our project approvals process, solution designs, sourcing decisions and project management. If our projects portfolio is going to impact our future IT costs to P&L by more than we can afford, then we need to recraft the business changes that plan to exploit technology, with no loss of busi- ness value, so future IT costs stay within our constraints.

In constraining a company’s overall IT costs, the CIO’s departmental budget is a red herring. Business decisions that cause the company to spend money on IT make the total IT costs what they are. Get those decisions right; then the most appropriate total IT spending, and IT budgets, emerge. That’s worth remembering when looking at IT costs, whether times are hard or not. CIO

Chris Potts is director of Dominic Barrow, an IT

strategy consultancy. To comment on this article,

go to www.cio.com/article/179251.

Think Tank CHRIS POTTS

Perfect Your Budget

For tips on how to pitch a winning It Budget, go to www.cio.com/ article/104609.

cıo.com

The CIO’s departmental budget is a red herring. Business decisions that cause the company to spend money on IT make the total IT costs what they are.

7 6 m ay 1 5 , 2 0 0 8 | www.cio.com

MAY15 COL THINK.indd 76 5/6/08 12:54:34 PM

Performance Measures

Developed by UMUC Faculty

What are performance measures?

• Performance measures are quantifiable indicators that are used to determine how well an organization or business is achieving its objectives

• One use of performance measures is to determine how well an IT system is doing in meeting the expected outcomes

• IT Performance measures include: • Quantifiable benefits from using an IT system

• When those quantifiable benefits should be realized, and

• How the results will be determined

When should performance measures be developed? • Performance measures should be developed as part of the business

case that proposes, explains and justifies the implementation of an IT system

• They are derived from the benefits expected from the proposed system

• They strengthen and help to defend the system proposal

Why do we need performance measures?

• Performance measures demonstrate how the proposed system is expected to impact the business

• Performance measures show how, when, and how much the system can be expected to improve the business

• Performance measures tell the decision-makers and stakeholders • What quantifiable benefits they should receive by implementing the system

• When they should realize those quantifiable benefits

• How the results will be determined- what will be measured and where the data will come from

What should be included?

• Business improvements that stakeholders are interested in • Financial improvements

• Improved customer service

• Improved customer satisfaction

• Improved (faster, less expensive) business processes

• Support for strategic goals

• Ability to expand the business

System Performance Measures • Such things as

• Availability • Reliability • Response time • Usability

• Not included in the business benefit performance measures • Stakeholders are focused on business measures • Stakeholders assume system will be expected to perform well

• System Performance Measures are still important and may be included in the list of requirements and Service Level Agreements with vendors

Project Performance Measures

• Such things as • Schedule/time to implement

• Cost

• Functionality

• Quality

• Not included in the business benefit performance measures • Stakeholders will be focused on these during the development period

• Stakeholders assume the project will be well managed

• May be included in SLAs or contracts with service providers

System and Project Performance Measures

• Stakeholders are interested in how the system performs and how well the IT project is managed

• These should be monitored and managed by the IT managers

• Stakeholders should receive regular reports on project progress and system performance

• In general, neither of these are meaningful as business performance measures

• These types of measures do not provide stakeholders with information about how the system improves the business

Developing “SMART” Performance Measures

• Specific – measures should be specific, clear, concise

• Measurable – need a metric (a “thing” that can be measured) that makes sense and is available

• Achievable – if measures are not achievable, do not include them

• Relevant – must relate to the business and be an expected improvement from the system being implemented

• Time-Based – target timeframe needs to be established

Documenting Performance Measures

• Performance Measures are documented using the following: • Expected Improvement (e.g., increased sales)

• Metric – what will be used to measure progress (e.g., monthly sales totals)

• Source of Data – where the metric data will come from (e.g., monthly report)

• Baseline – the starting point (e.g., current monthly sales)

• Target – estimated improvement point (e.g., monthly sales after system implementation)

• Timeframe – when the target should be reached (e.g., six months after system implementation)

• Performance Measures are often documented in a table, as shown on the following slides

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

This example uses a repair shop, for which the proposed system will reduce the time it takes to log an item in for repair. The expected improvement – decrease time to log in item for repair – is entered in the first column.

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

Time to record item entry into the repair process

The metric – the “thing" that can be measured to determine if login time is being reduced – is the actual amount of time it takes to complete the task. In this example, we will be comparing the time it takes to manually get out the log book, write in all the information and write a receipt for the customer – to an automated process where the data is entered through a computer screen and a receipt is automatically printed by the system.

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

Time to record item entry into the repair process

Task observation and stopwatch reading

Next, we have to determine where the data will come from to tell us how we are doing. In order to determine the amount of time needed to login an item, we will observe someone performing the task and measure the time with a stopwatch.

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

Time to record item entry into the repair process

Task observation and stopwatch reading

Four minutes

The baseline column shows what the source of the data shows for the current way of doing business, prior to system implementation. In our example, it will be an observation with a stopwatch to see how long a manual login and receipt creation take. It shows four minutes for the current process.

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

Time to record item entry into the repair process

Task observation and stopwatch reading

Four minutes Two minutes

The target shows what improvement is expected. We need to estimate how long the login and receipt generation process will take after the system is implemented. The estimate is that it will take about a minute for the clerk to enter the data into the system and about 30 seconds for a receipt to be printed. Adding a little slack time for slow data entry, we set the target for 2 minutes.

Table of Performance Measures

Problem or Expected Improvement

Metric – used to measure

Source of Data Baseline Target Time-frame

Decrease time to log in item for repair

Time to record item entry into the repair process

Task observation and stopwatch reading

Four minutes Two minutes Two weeks after implementation

The final column provides the timeframe by which the target should be attained. It could be immediately after the system is implemented, or in a longer time period. For this example, it is predicted that by the end of two weeks after system implementation, the clerk should be familiar enough with the system to login an item and print a receipt within the targeted two minute timeframe.

Using the Performance Measures

• Performance measures are not to be developed and forgotten

• Regular progress reports should be provided to the IT Governance Committee and other stakeholders to apprise them of progress toward meeting the goals

• Additional measures beyond those initially conceived may be added during the life cycle of the system

• Achievement of the performance measures forms part of the analysis of whether the system was a success or not, and should be considered when future system proposals are developed

In Summary

Performance Measures

• Help justify a system proposal

• Focus on business benefits

• Clearly show how the business will benefit by implementing the system being proposed

• Gain the support of decision-makers to implement the system

• Demonstrate achievement of the system objectives (or not)