controlling project progress, management & cost by ...

2 downloads 0 Views 357KB Size Report
Jones Carpers book in 1996, on „Patterns of. Software Systems Failure and ..... Jones Capers, „Patterns of Software. Systems Failure and Success‟ 1996. 11.
CONTROLLING PROJECT PROGRESS, MANAGEMENT & COST BY PIVOTING THE REQUIREMENTS PROCESS. Evangelos Markopoulos

Javier Bilbao Laxantere

Dominic Konditi

Department of Informatics

Department of Electrical Engineering Technical University of the Basque Country Bilbao, SPAIN

Department of Computer Science JOMO Kenyata University

University of Piraeus, Piraeus, GREECE

Nairobi, KENYA

Abstract: As projects become more software intensive, their management and implementation complexity increases. Managing software projects is actually managing complex projects. A software product or project is considered to be a brain product. Having to manage the way an individual or a team thinks towards delivering a project successfully requires more management capabilities than individual experience. Project management methodologies, practices, approaches, tools and standards have been and keep on being developed for the same purpose, to run a project on time, budget, and quality. This paper presents a project management approach based on a special role of the requirements management concept, one of the most critical processes in systems development and acquisition. By pivoting the requirements process, all system development or acquisition processes refer to the requirements to verify progress, and success in technical, financial and quality level. This paper presents this requirements based project management approach in both theory and practice.

1. Introduction : Over the last twenty years software engineering supports the management of complexity in software and systems development. Managing the software process can be more complex than managing the technologies used to develop the software itself [1] [2]. Project management has been viewed so far under a number of perspectives, approaches and conceptions. Each organized and structured attempt to manage an information technology project, and especially a software project, resulted to the creation of another best practice, which became later on a standard, guideline or remained as a best practice on a local or international level. Despite the fact that process management has been considered as a significant factor in successful project management, not much progress has been done. While the systems complexity increases the management effort to keep a project within budget, quality and schedule grows exponentially[3]. As computer hardware costs continue to decline, the demand for

new software applications will continue to increase at a rapid rate[4] since the existing software inventory continues to grow, and the effort required maintaining it continues to increase as well. At the same time, there is a significant shortage of qualified software professionals [5]. Meanwhile, the software development scene is often characterized by schedule and cost estimates that are grossly inaccurate, software of poor quality, and a productivity rate that is increasing more slowly than the demand for software [6]. 2. The Software Crisis This situation has often been referred to as the “software crisis” [7]. Even that this software crisis had been predicted and analyzed more than fifteen years ago, in now days not much has changed [8] [9]. The complexity for managing an information technology project has been carried along through the complexity on understanding the user needs and their expectations from technology. Jones Carpers book in 1996, on „Patterns of Software Systems Failure and Success‟ [10] indicates sixteen success / failure factors.

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

Nine of them are project management related, indicating the lack on planning, estimating, tracking, progress reporting, milestone control, risk management, configuration control and above all bad requirements. Carpers also relates the success / failure project factors with social factors related to the management practices. The ones that stand out the most are the ones related with the human factor and the project management maturity of the ones performing project management. The lack of communication and process interpretation are the most significant ones with the upper management in a negative role. The „Chaos Report‟, by The Standish Group International, Inc. in1995 [11] also indicates the requirements process as the most significant one for most of the disasters. Almost 42% of the successful project factors were based on the user involvement, the requirements quality and the executive management support. In a similar way almost 45 % of project failure factors were based on lack of user input, incomplete and continuously changing requirements and lack of executive management support. The report states this crisis by indicating that 31% of the projects studied was cancelled before completion, 53% of the projects overran by 50%, and only 9% of projects in large companies delivered on time and within budget, primarily because of bad requirements. As users understand the power of technology, they keep on coming up with requirements that stretch the system‟s implementation capabilities to the maximum [12]. On the other hand, managing complex and also incomplete requirements makes project management look like a Herculean task. This phenomenon has made no methodology, standard or guideline, to be able to stand as a tool or best practice towards managing all types of information technology projects. Every project today seems that it needs a unique project management approach, which must balance the project‟s technology constraints, user constraints and volume constraints. Understanding the environment and the constraints around the

Markopoulos E., Bilbao J., Konditi D.

project is significant towards drawing its implementation management strategy [13], [14], but understanding the project requirements is actually critical towards executing a project implementation and management strategy [15]. 3. Requirements based project disasters Software and system requirements are the beginning and end of each project‟s description. Many software projects fail because they have poor requirements and poor quality attributes on those requirements [16]. Prioritizing requirements is a very important concept in the requirements management where both the client and the supplier must be involved towards identifying the project success definition [17]. The damages that can occur as a result of the mishandling of an information technology project and even worse from the development of a bad IT system have been initially conceived in 1980 when Barry Boehm in his book “Software Engineering Economics” [18], identified and calculated the process of developing and managing IT projects against the development and management cost of the project, the investment and its impact on the organization. The whole concept of improving the information technology processes in the development and project management has started a few years later, in 1982 when the U.S. Department of Defence (US-DoD) after an investigation held by the General Accounting Office (G.A.O.) announced that only 2% of the information technology systems were functional at delivery, 3% could function with the implementation of additional changes, 19% functioned but they were quickly abandoned, 30% were never delivered although they were totally paid for, 46% were paid for, delivered, but never functioned. The prime cause of all these failures was insufficient requirements management processes which lead to incorrect and improper project management, causing projects to be financially unpredictable, unprofitable, operationally risky, insecure and/or of bad quality.

2/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

Loosing track of the requirements leads to loosing track of the project implementation process, since requirements affect significantly the implementation strategy. The cost of catching a missed requirement and correcting it in the analysis phase of the implementation process is nearly from 0,1 (10%) to 0,2 (20%) more than the initial requirement implementation cost. The cost of catching and fixing a missed requirements in the design phases is 0,5 (50%), in the coding phases is 1,0 (100%), in the unit test phase is 2.0 % (200), and in the acceptance test phases is 5,0 (500%) more than the initial requirement implementation cost.

4. Requirements need and categories. A requirement is something that a project must do or a quality that the project must have. A requirement exists either because the type of the project demands certain functions or qualities, or the client wants that requirement to be part of the delivered product. [12]. Groups of requirements define product or system functionality and groups of functions define the operations and of the entire product or system. The requirement is the beginning and the end on any initiatives, either developing a system / product, or acquiring a systems / product. Requirements must be specified before attempting to construct any product or develop any project. Incorrect requirements do not support correct product or project design and build, but above all do not enable users to use the systems developed. It has been recorded that 60% of the errors in a system occurred after the system has been delivered, are due to insufficient requirements [19], [20]. Systems or product requirements can be categorized in functional requirements, non functional requirements and constraints. The functional requirements are the ones directing the functionality of the product / project. They are the „must do‟ requirements, supporting actions that the product must take it is to provide useful functionality to the user. Non functional requirements, usually attached to the

Markopoulos E., Bilbao J., Konditi D.

functional requirements, are properties or qualities that the product developed must have. In some cases the non-functional requirements are critical to the products success, and other times are just requirements because they enhance the product. Constraints, finally, are global requirements. They apply to the entire product and are preferably defined before beginning work on gathering the requirements.

5. The role of the Requirements in the Systems Development and systems Acquisitions projects. All organizations today that can be considered as software and/or technology intensive organizations [21], can be roughly placed in two categories. The ones who develop technology and the ones who acquire it. The first category of organizations cover the ones which have internal software development or systems development teams that either produce IT products, services or applications and systems that support their operations and functionality[22]. Organizations in this first category usually perform project management by following mainly the engineering practices. Project management to those organizations is usually based on the proper execution of the development phases and the system‟s lifecycle model in general, within budget, schedule and quality, which is measured primarily by implementation performance and compliance to the requirements [23]. The second category covers all the other organizations excluded from the first one. The organizations in this category do not have the maturity, capability and needs above all, to develop their own information technology systems. These organizations use the technology not creating it. The primary goal of the organizations belonging to this category is to receive / accept a system that will function according to their requirements within a predefined budget and schedule. Project management for those organizations is based the management of the procurement / tender process (through which the vendor is

3/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

selected), the management of the signed contract, the management of the deliverables of the project and actually the management of time and material against the requirements related to project quality, cost and schedule [24].

the structure of the project and based on this structure they are getting evolve along with the maturity of the project owner.

Technocratic Approaches on Requirements Management Projects fail due to insufficient requirements, products fail for the same reason, investments fail also for the same reason, and eventually behind every failure the prime failure cause is a misconception on the requirements concept. Some people did not gave requirements, others gave fuzzy requirements, others did not understood them, others thought they understood, others gave the requirements late in the project and others didn‟t asked for them promptly. If one does not know where to go, no map can help. It is getting very tired to keep on writing information technology project failure stories due to poor requirements management practices. Loosing track of the requirements and the project goals, and expectations as well is not very difficult. The requirements need not only to be well defined but also verified and aligned with the expectations and goals of the project. Figure 1 presents a common problem in project management and specifically in requirements management. The existence of requirements does not guarantee the correctness of the requirements and their contribution on the project [25] Moving from the perceived requirements to the fulfilled requirements, is very easy to lose control of what is finally being developed, if effective requirements management processes are not in place before, during and after the implementation of a project. The requirement process needs to be redesigned conceptually and practically. A project begins with requirements in the project identification phase, far before the project implementation phases. The initial, vague, and incomplete requirements form

Markopoulos E., Bilbao J., Konditi D.

Figure 1. From the perceived to the fulfilled requirements

Requirements are not been taken after the project implementation has started, they can be verified, or clarified, but not identified after that. The requirements for both types of projects, development or acquisition need to be generated, way before the project starts to be implemented. Figure 2, presents a model on requirements management [25]. It can be clearly noticed the role of the requirements on the project concept, as well as the association of the requirements with the tender and the proposals processes. actual needs

perceived needs

expressed expectations

selected requirements

call for tender

design and development

specified requirements

proposal

customers’ satisfaction: quality view

delivered product: fulfilled requirements

conformance: contract view

Figure 2. A holistic approach on requirements management

This concept is not relatively new, but not quite common as well. The SEFER methodology is one of the first methodologies which associated the requirements management with the tendering process, and the tendering process with the project implementation and the project management [26]. The same approach is also present in the ARIADNE methodology which divides the project management approach in managing the

4/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

development process or managing the acquisition process, or both with combination of processes [27]. In both cases the ARIADNE methodology builds the appropriate management model based on the role of the requirements prior to the implementation of the project.

6. Pivoting the Requirements Process As the management of requirements can control the project success or failures, requirements must be treated with more consideration throughout the entire system development or acquisition process. The new role of centralizing the requirements management phase or initiative, and having all other processes to be used, implemented, measured and monitored based on the requirements completion, cohesion, validation, verification and consistency, demand the requirements process to have a pivot role on which all other systems development and engineering activities will be implemented based on the requirements. In the systems development process, all development phases can be based on the requirements concept. Requirements elicitation, validation and analysis activities usually take place before the implementation of the project [28], [29]. The requirements can be developed by either developers or other groups of people (non systems developers), such as the business analysts, domain experts or business experts, in collaboration with the customers, government regulations, corporate goals, needs or market trends [30]. In this case, the requirements form the backbone of managing the execution of the development process. By managing the evolution of the requirements from plain text, to analysis diagrams (use cases, etc), to design diagrams (activity, stage, deployment diagrams, etc), to code, to test cases, to documentation paragraphs, to acceptance scenarios, to operation indexes, etc, qualitative project management can be obtained [12], as well as cost management. The requirement can be perceived as a living organism, or as reference point to every engineering activity that supports any

Markopoulos E., Bilbao J., Konditi D.

development life cycle process under any development model. By pivoting the requirement process the requirements become the base that enables project tracking and measurement on even human resource management activities, to enter into the so called „engineering practices‟, transforming this way a system development methodology, into a systems development framework. Figure 3, presents the requirements management process on a systems development model. R Analysis e q u Project i Planning r e m Design e n t Develos pment

M g m t

Project Management Activities

Integration

Testing

Installation

Operation

Documentation

C h a n g e

R i s k

P r o j.

P r o j.

T r M Ma g g c m mk t t i n g

T e a m

Acceptance

Figure 3. Pivoting the requirements management process in the development life cycle.

The concept of managing all engineering activities in systems development, based on the requirements has been adopted my many methodologies. The ARAIDNE-SE methodology [27], as presented in figure 4, is perfectly aligned with this concept. Once the requirements have been identified the development project begins. Using the requirements management process as pivot in the effort to manage the development process, the requirements document leads a series of inspections, reviews and walkthrough in all development phases. Base on the requirements, the analysis of the system is being executed, inspected and accepted. The system design inherits the system analysis deliverables and the design

5/9

M g m t

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

of the system is generated in such a way that all requirements passed from the analysis, are included in the design. Design reviews are conducted to verify that the design is also aligned with the requirements and the analysis as well. The same process is applied consecutively in all other development phases as well. If deviations from the requirements are found, they must be defended and documented in order to be accepted or rejected by the project management and quality assurance teams.

… based on the needs Requirements

… based on the requirements

Request for Proposal s

… based on the RFP responses

Contacting

… based on the RFP

Subcon tracting 1-n

…based on the contract

Acquisition Management

Project Impelmentation

…based on the methodology

Figure 6. Leading role of the requirements in the system acquisition process

Figure 5. The ARIADNE-SE Methodology for Systems Engineering (SE)

The requirements pivoting concept can also be applied in the system acquisition methodologies and initiatives. Managing the acquisition effort is based heavily on managing the projects requirements quantitatively and qualitatively. Figure 6, presents the leading role the requirements can take on the system acquisition process by defining the project, leading the tendering process, support the projects contract and track the project implementation. The leading role the requirement can take in the system acquisition process can support the requirement pivoting concept on system acquisition projects as well as shown in figure 7. Once the project has been identified and the project requirements have been created, the tendering process begins with the development of the request for proposals and the evaluation of the suppliers‟ offers.

Markopoulos E., Bilbao J., Konditi D.

The requirements in this case, provide the raw material for implementing the tendering process. The requirements role on an system acquisition project supports heavily the implementation period of the project. During the project implementation, the requirements are used to track, inspect and review all project implementation processes and activities performed by the supplier. Scope Requirements management Project Proposal

Project Planning

Plans for resourcing

Management structure

Beginning of Project Implementation Contract Tracking and Oversight Evaluation Project tracking and oversight Deliverables management Quality Assurance Change management Risk management

End of Project Implementation Transition & Support

Acceptance Post-Impementation Eval.

Figure 7. Pivoting the requirements management process in the systems acquisition process.

6/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

In general, pivoting the requirements for the development or the acquisition process is quite similar. In each process the requirements are used to track down the implementation process and to manage the projects cost, schedule and quality from different perspectives. Engineers pivoting the requirements process in order to make sure that what they are developing is what they must develop, with no functional and non functional deviations, while clients pivoting the requirements process in order to make sure that what they are acquiring is based on what they have planned and expect.

This difference can be turned into budget overruns based on the cost allocated for the implementation of the analysis phase. By identifying delays in early phases the project manager can forecast the delays in the project completion and calculate possible financial damages both in the project implementation cost and indirect damages that can derive from the project‟s operation delay. The same scenario can be applied in the systems design phase, in the coding or parameterization phases, etc, giving total or partial project budget management based on the completion of the requirements implementation per phase, per function, subsystems etc.

7. Project Progress and Cost Controls

Treating the requirements as single and unique elements it is possible to calculate the project progress status, associate it with the project schedule and then with the budget. In other cases no progress estimation can be derived at phase completion level and at project completion level. Lack of measurable progress estimation results to fuzzy project progress tracking which in turn leads to lost of project control at every level.

Having the requirements management process as a pivot in the systems development and acquisition process, a number of metrics can be generated supporting the project in term of budget, schedule and quality management. A progress report, indicating the completion of a project, can be strongly developed if requirement pivoting has been applied in the systems development phases. In this case, the progress is estimated by the number of requirements implemented per phase, and by the number of phases in the project implementation methodology. If for example 70% of the requirements have been analyzed, 50% have been designed, 20% have been coded, and 10% have been tested, the project progress can be estimated by calculating the completion of the requirements implementation at a given time over the total number of requirements per function, subsystem, or the project as a whole. On the other hand requirements implementation and completion can also be associated with project schedule and project cost. If for example, 70% of the requirements have been analyzed in three weeks in the system analysis phase that should last two weeks, then serious delays in the project implementation are recorded. The time required for the requirements to be analyzed is the difference between the estimated completion of a specific implantation phase and the actual time.

Markopoulos E., Bilbao J., Konditi D.

8. Risks and Prerequisites on using the Requirements Pivot Concept Every new concept introduced is highly associated with risks in its understanding, planning, implementation and management as well. Using the requirements management process as a pivot in the management of the development or the acquisition of a system can create more problems than the ones intended to solve, if no experience in requirements engineering is present in the project implementation and management teams. In order to track a project based on its requirements, the requirements elicitation process shall be executed in such a way were each requirement can be characterized as a system‟s entity in functionality of quality. If that is not possible to be achieved in one requirement, then a group of requirements can be considered as one in order to have this entity identity. Requirement verification and validation is also an essential prerequisite in order to

7/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

apply the requirements pivoting concept in project management by requirements. Incomplete requirements, contradictory requirements and requirements that are repeated must be eliminated from the requirements document that will lead this initiative. Having each requirement as a project implementation element, groups of requirements, related to each other can be generated. Each requirements group will have a requirements group weight in implementation time and budget. A number of requirements groups can form a function, groups of functions can form a subsystem, subsystems can form a system and systems can possible form the project. Trying to add weights in single requirements can be very tedious, risky and error prone in both budgeting and scheduling tracking, placing in risk the whole pivoting concept as well.

implementation based on the requirements completion and coherence. This pivoting concept is approached is both the system development process and in the system acquisition process in an attempt to cover the engineers who develop a technology and the clients who acquire a technology respectively. The proposed requirements pivoting concept is introduced in a theoretical and empirical base. Further research will follow in order to develop all required models and algorithms that will support this work and the pivoting concept towards applying it successfully on every type of project under any conditions.

10. References 1.

9. Conclusions and further research

2.

As technology gets mature, so does the users and the engineers. Managing maturity is managing complexity. System development techniques and system acquisition requirements become more and more complex since technology gives the feeling that impossible is nothing. System requirements become more and more complicated and so does their implementation and management. Managing projects successfully is heavily based on managing the implementation of the requirements successfully. Lost of requirements management can easily result to lost of scheduled implementation deadlines which in turn result to lost of implementation budget allocation, and so on. This domino effect can result in some cases the deterioration and termination of the entire project or changes in the project scope and objectives. Trying to avoid this mess special attention has been given in managing successfully the root of this problem which is the requirement. This work contributes to this problem by presenting the concept of pivoting the requirements process and executing project management activities on the project

3.

Markopoulos E., Bilbao J., Konditi D.

4.

5. 6.

7.

8.

9.

10. 11. 12.

13.

Rai, A., Song, H., Troutt, M., „Software Quality Assurance: An analytical survey and research prioritization‟, Systems Software, Elsevier Science, 1988, pp. 67-83. Dijkstra, E.W., „A Discipline of programming‟, Prentice Hall, 1976 Boehm B., „Software Cost Estimation in COCOMO II‟, Prentice Hall, 2000\ Mills E., „Software Metrics‟, SEI Curriculum Module SEI-CM-12-1.1, December 1988 Metagroup, „IT Performance Trends 1999‟, Rubin Systems Inc, 1999 Arthur, L. J. Measuring Programmer Productivity and Software Quality. New York: John Wiley, 1985 Gibbs W., „Software‟s Chronic Crisis‟, Scientific American, vol. 271, no. 3, pp 86-95, 1994 Glass, R., „Is there really a software crisis‟, IEEE Software, vol. 15, no. 1, January 1998, pp.104-105 Gibbs W., „Software‟s Chronic Crisis‟, Scientific American, vol. 271, no. 3, pp 86-95, 1994 Jones Capers, „Patterns of Software Systems Failure and Success‟ 1996 The CHAOS Report, The Standish Group International, Inc., 1995. Robertson S., Robertson J., Mastering the Requirements Process, Addison Wesley, 1999 Bergey J., Smith D., Tilley S., Weiderman N., Woods S. Why

8/9

Controlling Project Progress Management & Cost by Pivoting the Requirements Process.

14.

15.

16.

17.

18. 19.

20.

21.

22.

23.

24.

25.

Reengineering Projects Fail. Technical Report, CMU/SEI-99-TR-010, ESCTR-99-010, April 1999 ISO/IEC 12207:1995, „Information technology-software life cycle processes – Amendment 1‟, 2002 Anton I., Successful Software Projects Need Requirements Planning, IEEE Software, Volume 20, May-June 2003, pp 44-46. Boehm. B., Hoh H., „Identifying Quality Requirements Conflicts‟, IEEE Software. March 1996, pp. 25-36. Karlsson, J., „Software requirements prioritizing‟, Proc. 2nd IEEE International Conference on Requirements Engineering. IEEE Computer Society, 1996, pp110-116. Boehm B. W., „Software Engineering Economics‟, Prentice Hall, 1981 Jerry Weinderg, „Quality Software Management : Volume 1 Systems Thinking; Volume 2 First Order Measurement; Volume 3 Congruent Action; Volume 4 Anticipating Change, New york, Dorset House, 1992-1997 Steve McConnel, „Code Compete‟, Redmond, Washington. Microsoft Press, 1993 Markopoulos E., „An Empirical Adjustable Software Process Assessment Model for Software Intensive SMEs‟, 7th European Conference on Software Quality, Conference Notes, Tampere, Finland, pp. 16-19, 2002 SEI, „SE-CMM - Maturity Model‟, SECMM-95-01, CMU/SEI-95-MM003, 1995 Markopoulos E., Panayiotopoulos J-C., „A Project Management Methodology Selection Approach based on Practical Project and Organizational Constraints‟, WSEAS Transactions on Computers, Issue 8, Vol 4, pp 934-942, August 2005 SEI. „SA-CMM. Technical Report‟, CMU/SEI-99-TR-002, ESC-TR-99002. 1999. Finn N. Svendsen, European Trends in Software Quality: Some Challenges in The Next Years‟, Proceeding of the 5th Quality Forum, Athens, Greece, 2000

Markopoulos E., Bilbao J., Konditi D.

26. Software Engineering Framework, SEFER, Version 3, Methoda Computers, Israel. 27. www.ariadne-methodology.com sited July 4, 2007-07-11 28. Reifer D., „Requirements Engineering‟, in Encyclopaedia f Software Engineering, Wiley, 1994, pp. 10431054 29. Holttzblatt k., and Carmel E., „Requirements Gathering: The human factor‟, a special issue of ACM, vol. 38, no. 5, May 1995 30. Wyder T., „Capturing Requirements with Use-Cases‟, Software Development, February 1996, pp 37-40

9/9