The significance of right timing for project review in software development projects

Abstract

Despite improving software methodologies and techniques, software projects are still perceived as unpredictable and costly. The cost associated with unsuccessful projects for the U.S. companies is around $145 billion per year (Philips, 2001, pg. 1). One major part of the problem is the management approach taken for defining, planning and executing product development. Unrealistic expectations can drive projects to failure. Asking the right questions at the right time of the project lifecycle becomes key to correct misperceptions in management. The main role of management is to coach the project team through the project life cycle. As a result management can adjust business decisions or correct the product directions in time.

This paper establishes a set of five basic questions, with subcategories, that can be applied for project reviews throughout the lifecycle of a product development. These questions are recommended to use for project reviews. Asking the right questions at the right time helps stakeholders get the information they need. Too many reviews can contribute to project failure, as too little reviews, or reviews at the wrong point of the project lifecycle. In order to identify the right timing for project reviews, we evaluate the relationship between product life cycle, project life cycle and software development methodology. We assess conventional software approaches such as the waterfall model and agile development methodologies to identify the best timing for the project reviews. The attendees take away guidelines for the timing of the review Milestones related to the development method used in the software project.

Introduction

The purpose of project management is to help transform business goals and objectives into a process to create products or services that generate revenue. It takes the definition of a goal, the expenditure of resources, knowledge, time, effort, risks, and investment (Input factors) to turn them into a product with revenue and customer (Output factors). Processes based on standards and methodologies effect the transformation of the Input factors to the Output factors. (See Exhibit 1).

Input and Output Factors of Project Management

Exhibit 1: Input and Output Factors of Project Management

Project Analysis

In order to deliver a high quality product to the market, it becomes critical to assess truthful project information throughout the duration of the project. Projects have to be managed within certain constraints which are a complex mix of time, budget, scope and quality, also called quadruple constraint model (Exhibit 2). Managing a project within these constraints builds the basis for a successful project outcome (Baker, 1992, pg.5-7). The culture and leadership style in an organization often determines the success of projects. Reviews are an essential means to evaluate the status of a project. To identify the project information two views must be taken: the product and the process view. Questions for the product view have the goal to identify more detailed product attributes. The process view questions help to understand what work flow and approaches are taken to create and roll out the product. Managers use their personal standards as well as the organizations value system to evaluate projects progress and success. Conducting regular project reviews helps management and the project team to make the right decisions.

Management of Key Constraints (Baker, 1992, pg.5-7)

Exhibit 2: Management of Key Constraints (Baker, 1992, pg.5-7)

Project reviews focus on the progress of the project and take place involving key project stakeholders. Stakeholders are all organizations or individuals who will be impacted positively or negatively by the outcome of the project (PMI, 2000, pg.208).

Project reviews differentiate significantly from the reviews of deliverables such as design reviews or code reviews that verify the correctness of specific work products.

It has to be recognized that reviewing a project costs time and resources now, (Chroust, 1999, September). Not asking questions will usually cost more time later. As it has to be acknowledged that time is critical for the success of a company the time focus also creates a big distraction for asking the right questions. The focus of the review questions is on obtaining information that can help to validate that the project is heading in the right direction and the approach taken is feasible.

We identified five basic questions for acquiring the right project information in Exhibit 3.

Five basic review questions

Exhibit 3: Five basic review questions.

Questions one, three, and four are seeking information about the product. Questions two and five analyze the process for creating this product. Although all five questions could be applied to both areas this assessment focuses on the specified selection.

Relationship of Product Life Cycle, Project life cycle and Software Methodology

The stages of the product lifecycle, project lifecycle as well as the software development methodology have an impact on when information becomes available during the project. Therefore it is essential to understand their relationship in order to set review milestones. Exhibit 4 takes an overall view and shows how product life cycle, product development life cycle (PDLC) and project life cycle overlap each other.

The commercial product life cycle is the concept that a product goes through several stages in the course of its life: market introduction, market growth, market maturity and sales reduction. At each stage, a product's marketing mix might change, as will its revenue and profit profile (Perreault, 1997, pg. 228-231). The product development lifecycle starts with the idea of a new product in an organization that gets evaluated during the innovation phase. It is followed by the product development phase. After the initial market introduction the product is adapted and then sustained and finally reaches its end of life.

The product development life cycle entails the project life cycle that defines the phases a project goes through from project initiation, then planning, followed by executing and finally project closing (Project Management Institute, 2000, pg.29-38). The project life cycle incorporates the development methodology that is the approach selected to develop the software product. Product lifecycle as well as project lifecycle processes are the key processes for transforming project Input factors to Output factors as demonstrated in Exhibit 1 of this paper.

Relationship of Product Life Cycle, Product Development Lifecycle and Project Lifecycle

Exhibit 4: Relationship of Product Life Cycle, Product Development Lifecycle and Project Lifecycle

Many organizations manage their software development activities in projects during the product development and product adaption phase. Therefore we will focus on these areas only for further assessment.

Software Development Methodologies

In this section we evaluate how different software development methodologies play a role in the project lifecycle. For this purpose we will assess the conventional waterfall-type method and agile methodologies. Based on the outcome we can set review milestones for each methodology.

We define the key review milestones by identifying the stage gates for the product development life cycle. Exhibit 5 shows the key review milestone for the product development lifecycle.

Management review milestones for the product development life cycle

Exhibit 5: Management review milestones for the product development life cycle.

The end of each stage of the PDLC requires a management review in order to identify the readiness of the product to move to the next stage. Each management phase end review is marked with a red diamond. Exhibit 6 provides an overview of the management review milestones of the PDLC when using a waterfall type methodology.

The management review for the PDLC

Exhibit 6: The management review for the PDLC

In the next step we break down the PDLC into the project life cycle for the product development phase. When a software product is developed by using a waterfall-type method, the initial product for market introduction gets developed within one project cycle. We can identify the review milestones. The project review milestones are marked as green diamonds in Exhibit 7. Exhibit 8 explains the nature of the review milestones.

Project review milestones for the product development phase of a waterfall type model

Exhibit 7: Project review milestones for the product development phase of a waterfall type model.

Project review milestone for the product development phase

Exhibit 8: Project review milestone for the product development phase

As soon as the product hits the market, plans are made for follow up releases to adopt the product to newly identified customer requirements. The product reaches the product adaptation in its product development lifecycle. We follow the same process to identify the review milestone for the product adaptation phase as described before. The results are shown in Exhibit 9. Exhibit 10 explains the project reviews for the adaptation phase. During the adaptation phase software update releases are created that entail feature enhancements. In general the methodology does not contain any Alpha or Beta testing efforts at this stage.

Throughout the initial product development and product adaptation, additional project reviews are needed whenever a variance occurs that is greater then defined in the project plan. A major slip of the schedule or a major budget overrun is usually an indicator that the project is not going in the right direction and a sign that misperception lead to unrealistic estimates and assumptions.

Review Milestones for the product adaptation phase

Exhibit 9: Review Milestones for the product adaptation phase

Review milestone for the product development phase

Exhibit 10: Review milestone for the product development phase

Agile Development Methodology

Agile development methodologies include various methodologies such as Extreme Programming, Crystal Methods, Feature Driven Development, Dynamic Systems Development Model, SCRUM, Adaptive Software Development or Lean Development (Schwaber, 2002), (Beck, 2000), (Abrahamsson, 2002). Some of them have been around for more than 10 years.

Requirements changes are common throughout the development lifecycle of a software project. The agile development methodologies can follow a moving target. The product is usually developed in increments rather than building the whole system or product at once.

This leaves the necessary room to introduce changes between the iterations. It also allows applying lessons learned from the previous iteration. In addition the developer can focus on certain features/functionality within the cycle. The details are specific to the methodology used.

During the innovation phase the product idea “the metaphor” is created and the associated business case is identified. The first review takes place where management makes their GO/NOGO decision for the project. The product development phase starts with a product level initiation and planning phase that is then followed by multiple iterations that run partly through all phases of the project management cycle. Each iteration contains planning, executing and closing activities. Dependent on the agile methodology one iteration can be between two weeks up to four months (Koppensteiner, 2004, June).

Exhibit 11 shows the review milestone for the product development life cycle and the project reviews for an agile development methodology based on Scrum as described in (Schwaber 2002), (Koppensteiner, 2004, June) and (Udo, 2003, September). Exhibit 12 summarizes the management and project review milestones for the agile methodologies.

Additional reviews are necessary if an iteration is exceeding its predefined target date for completing the product increment. If there is a major delay the iteration needs likely to be cancelled and re-planned.

Management and project review milestones for agile development methodology

Exhibit 11: Management and project review milestones for agile development methodology

Review milestone for agile methodologies

Exhibit 12: Review milestone for agile methodologies

Conclusion

We identified five basic questions that provide the baseline for progress reviews of a software product development. This set of questions is defined to focus management on the product and process direction rather than on the timeline itself.

Two specific management reviews can be differentiated, the general management review and the project review. As a general guideline management reviews take place at the end of each phase or before entering a new stage of the product development lifecycle.

To identify the timing for project reviews we assessed the relationship between product lifecycle, project life cycle and software development methodology.

Management reviews take place before each product release to the market to verify market readiness. Further we evaluated two different software development methodologies: a waterfall-type model where activities take place in sequence and agile development methods that are founded on iterations. We demonstrated how each methodology relates to the product development lifecycle and project life cycle. Each methodology is following a different work flow model that influences the timing for project reviews.

We conclude that the relationship between the project life cycle and the work flow of the software methodology determine the timing for the project reviews.

Additional project reviews are required whenever a variance occurs that is greater then defined in the project plan. A major slip of the schedule or major budget overruns are usually an indicator that the project is not going in the right direction and a sign that misperception lead to unrealistic estimates and assumptions.

References

Abrahamsson P., Salo O., Ronkainen J. & Warsta J. (2002) Agile software development methods, Review and Analysi”, ESPOO 2002 VTT Publications 478; retrieved on March 18th 2003 from http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf.

Baker S. & Baker K. (1992.) On Time/On Budget, A Step-by-Step Guide for Managing Any Project, Prentice-Hall:New Jersey.

Beck K. (2000) Extreme Programming Explained. Addison-Wesley: New Jersey.

Chroust G. & Lexen H. (1999, September) Software inspections-theory, new approaches and an experiment. EUROMICRO Conference, 1999. Proceedings. 25th, pp. 286 - 293 vol.2. Milan, Italy.

Koppensteiner S. & Udo N. (2004, June) How Agile Software Methodologies Influence the Role of the Project Manager. 19th IPMA conference, Budapest, Hungary.

Perreault W. & McCarthy E. (1997) Essentials of Marketing, A Global Managerial Approach, pp.224-226, IRWIN: USA.

Phillips J., Bothell T.& Snead G. (2001) The Project Management Scorecard, Measuring the success of project management solutions. Butterworth-Heinemann:USA.

Project Management Institute. (2000) A guide to the project management body of knowledge (PMBOK® Guide). Newtown Square:PA.

Schwaber K. & Beedle M. (2002) Agile Software Development with Scrum. Prentice Hall:New Jersey.

Udo N. & Koppensteiner S. (2003, September) Will Agile Development change the way we manage Software Projects,. Agile from a PMBOK Guide Perspective, 2003 PMI Global Congress, Baltimore, Maryland, USA.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2006, Sonja Koppensteiner InterGlobe Consulting
Originally published as part of 2006 PMI Global Congress Proceedings-Madrid, Spain

Advertisement

Advertisement

Related Content

  • PM Network

    Agile Infusion member content locked

    PM Network interviews Benjamin Marais, CIO at Liberty Group South Africa.

  • PM Network

    Tame the Haters member content locked

    By Fewell, Jesse "We want to be controversial for a moment and propose an end to projects and project management." So goes the opening chapter of #Noprojects: A Culture of Continuous Value, a book published this…

  • PM Network

    One For All registered user content locked

    By Pincot, Lenka How many times have you heard IT staffers complain about unrealistic requirements from business teams? And how often have you listened to colleagues from the business side gripe that new tech tools…

  • PM Network

    Agility in Motion registered user content locked

    Electric bikes aren't exactly known for their aesthetics. But, with its most recent product-development project, the French upstart Coleen looks to change that, taking Jean Prouvé's classic World…

  • PM Network

    Degrees of Uncertainty registered user content locked

    By Fewell, Jesse If you've never heard project managers debate the merits of agile, here's a quick summary. A gruff project manager says, "Since your agile approach doesn't fit my oil exploration projects, it's not…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.