Use of agile methodology for IT consulting projects

College of Business
Western Carolina University, Cullowhee, NC

MANGA ANANTATMULA

Project and Knowledge Concepts, Inc., Oak Hill, VA

Introduction

Projects are often the means to operationalize strategic plans of an organization. Projects are envisaged to develop products and services, and to gain operational efficiency. Business is becoming increasingly projectized and global spending on projects is in the order of many billions of dollars annually (Williams, 2005). The reasons are obvious. Projects provide an opportunity to employ project management practices that promote efficient and effective use of resources. However, in spite of advances in the project management discipline and profession, the common experience suggests that many projects fail (Williams, 2005), which underscores the importance and the need to improve project management processes and performance.

In general, organizations strive to implement best practices of traditional project management—based on PMI standards—to accomplish project objectives and to meet customer's expectations. However, not all the recommended processes and practices of the Project Management Body of Knowledge (PMBOK® Guide) may be relevant for every project. Often, a selective approach makes sense in adopting project management processes and practices to suit specific needs of the project based on its size, type, complexity, and the industry in which the project is undertaken. Such a need for a different approach to managing IT projects is well documented in the project management literature.

Software development projects often face conflicting challenges of developing software products at an accelerated pace while developing them with a robustness to make them dependable (Boehm, 2002). IT projects, aiming to keep pace with the fast-changing technology developments, often undergo scope changes during the planning and implementation stages. Consequently, IT projects have challenges that are different from traditional projects. Several adjustments and modifications to traditional project management practices are developed and practiced for IT projects, thereby introducing new project management methodologies such as agile project management.

Agile project management methodology—with its greater adaptability to frequently changing scope—uses iterative or phased planning and continuous integration. The key principle is to keep the project scope soft. The methodology promotes collaboration and results in increased customer satisfaction. However, agile is not a complete solution for developing software at a fast pace while meeting customer's demands of robustness and dependability. In this context, Boehm (2002) recommended a combination of traditional project management and agile software development methodology that is feasible and preferable. A complementary approach would be to develop a risk-based approach that is tailored to retain the benefits of both agile and plan-driven methods and at the same time mitigate many of their weakness (Boehm & Turner, 2003).

This research paper aims to examine the above propositions (Boehm, 2002; Boehm & Turner, 2003) of a combined approach for managing IT consulting projects, which are different from IT projects. IT consulting projects are conceived to manage and provide project support to IT projects. They are often initiated in the government sector. IT consulting projects are not software development projects; rather, they provide project support to IT projects.

In this study we aim to develop an understanding of how agile project management practices are relevant for IT consulting projects. The objectives of the study are to identify benefits of using agile project management, its suitability, and what aspects of traditional project managements can be combined with agile project management for IT consulting projects to improve project performance. In the next section, using an extensive literature review of agile project management methodology, we have identified salient features of the agile method and their unique approach to managing projects as compared to traditional project management. The literature review has helped to develop an understanding of the key concepts and benefits of using agile software development. Further, based on literature review findings, we have developed and presented a research method using a structured questionnaire to develop an understanding of IT consulting projects. Data analysis and discussion, presented subsequently, provide important insights and findings of the study. We conclude the paper with our research findings and recommendations for IT consulting projects.

Literature Review

Traditional project management practices, which are driven by comprehensive planning, can be used when project specifications are clearly defined. On the other hand, when specifications are subject to frequent changes during the life of the project, the traditional approach to managing projects may not work efficiently. Software development projects often are conceived with minimum specifications, causing frequent changes to these specifications during project implementation. Further, software project development durations are short. Agile methods, compared to traditional project management techniques, are suitable for software development projects because of these projects' short duration for development (Hanakawa & Okura, 2004).

In general, various software development methods such as agile project management promise increased customer satisfaction, lower defect rates, faster development times, and they serve as a solution to rapidly changing project requirements (Boehm & Turner, 2003). In contrast to agile project management, a stage-gate model uses a work process from concept idea to a product that is ultimately delivered. This model develops project management lifecycle phases based on different stages of product development for managing projects. An important distinction between a stage-gate model and agile project management is that the former attempts to minimize requirements changes so that the product is completed in time (Karistrom & Runeson, 2005). Another method for developing software is SCRUM, which is a set of project management principles employing small cross-functional and self-managed teams (Schatz & Abdelshafi, 2005). SCRUM requires that each team member and product owner work together at the beginning of each development item and the methodology acts as a wrapper around existing development processes. Therefore, Schatz and Abdelshafi argued that SCRUM will not have a baseline plan to measure project success. However, agile project management is considered for this study because of its greater flexibility and adaptability to software development projects.

In addition to the benefits discussed above, agile methodology is applicable to turbulent and constantly changing environments (Highsmith & Cockburn, 2001). Further, the agile method emphasizes adaptability to market, technology, and process (Mellor, 2005). The agile methodology is an approach that will focus on important features first, and as a result, it will look for early feedback on features (Karistrom & Runeson, 2005). Once important features are identified, the project manager will ensure that there are no delays. Karistrom and Runeson indicated that the agile process would avoid cramming of resources, fixed plans, and supporting long-term plans.

However, agile methodology is not suitable for all software development projects. Citing Scott Ambler, the developer of the agile method, Boehm (2002) recommended traditional, plan-driven project management methodology for assurance software such as life-critical systems.

The agile method, due to its demanding project environment characterized by chaos and uncertainty, need project teams comprising of talented people to meet challenging needs and demands. Citing a research study by Constantine (2001), Boehm (2002) suggested that agile methods require highly capable people. Further, agile is not suitable for larger teams (Highsmith & Cockburn, 2001), as it requires tightly coordinated teamwork to succeed, and teams with more than 15 or 20 developers increase the difficulty of managing the project (Constantine, 2001).

It is obvious that the agile method employs coherent teams (Karistrom & Runeson, 2005). Karistrom and Runeson identified additional agile features, such as small and manageable tasks, continuous integration, and automatic testing. Consequently, agile project teams are characterized by good internal communication, higher quality, and a feeling of being in control (Karistrom & Runeson). They, however, envisage potential isolation for the agile team.

In terms of communication, document-based management of progress, and quality control, a common practice in traditional project management does not match with agile software development method (Hanakawa & Okura, 2004). Face-to-face interaction for continual realignment of development goals is usually preferred in agile methodologies (Melnik & Mauer, 2004). Highlighting the difference between traditional and agile methods, Melnik and Mauer suggested that short knowledge transfer and direct communication and collaboration are preferred in software development, in contrast to the traditional project management practices, where long knowledge transfer chains are used, which are often susceptible to distortion and loss of information.

One of the important differences between plan-driven traditional project management practices and agile methods is that agile methods capture the agility from the tacit knowledge of the project team rather than the explicit knowledge, often used in the form of documents and plans in traditional project management (Boehm, 2002).

Another difference is the amount and type of documentation created for projects. Plan-driven traditional project management emphasizes detailed planning, monitoring, and controlling documents. Design rationales, documents that express reasons and justifications, are created using a highly automated procedure and these design rationales serve as agile documentation (Sauer, 2003).

Coram and Bohner (2005) have identified common features of the agile method: collaboration, small teams, short release schedules, time boxing, and constant testing. The project manager is responsible to ensure a highly collaborative environment. For this purpose, the agile method encourages small teams and a few sub-teams per project to foster collaboration. As a consequence, the agile method is likely to require less process and planning to coordinate team activities. The agile method also uses short release schedules, which may vary from two weeks to six months. Time boxing is a concept that imposes fixed duration for the release of project deliverables, which helps reduce gold plating and scope creep. Constant testing ensures product quality and integration. Furthermore, Coram and Bohner suggested that project managers must track progress and make business decisions with an emphasis on responding to change rather than following a specific plan.

Time boxing leads to unpredictable planning by best guess and fixed dates could bring on unexpected surprises during the development phase (Patton, 2003). Another upshot of this iterative project planning process is that the agile method cannot monitor the progress based on percent complete (Patton, 2003).

The involvement of small sub-teams in planning will result in motivated software development engineers; technical issues are raised early in the project and there will be little resistance in implementation (Karistrom & Runeson, 2005). In addition, defining project scope with an agile approach would result in cost reduction (Mcgovern, 2002). The agile method uses requirements based planning, and will also let us control scope (McGovern).

Using all the references and discussions thus far and others (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), Table 1 provides a summary comparison between traditional and agile project management practices.

Table 1: Comparison between Agile and Traditional Project Management

Project phase Traditional Agile
Initiation
  • Formalized project
  • Capability
  • Quality
  • Foreseeable, evolution requirements
  • Formal communication policies
  • High assurance and stability approach
  • Prioritized
  • Informal stories
  • Test cases
  • Unforeseeable rapid change
  • Informal, face-to-face communication
  • Radical change and rapid value approach
Planning
  • Documented
  • Explicit documented knowledge
  • Formal plan
  • Comprehensive approach
  • Well-defined scope
  • Slow change in scope (approved)
  • Predictability
  • Optimization
  • Plan-driven resource allocation
  • Low risk because of plans
  • Inflexible plan and scope
  • Extensive use of quality control and tools
  • Plan- and business-driven project
  • Plan-driven schedule
  • Less-documented driven flexible plan
  • Tacit interpersonal knowledge
  • Iterative plan
  • Requirements-driven approach
  • Changing scope
  • Frequent, radical changes
  • Unpredictable
  • Requirements-based, felxible
  • Need-based resource allocation
  • High risk, unpredictable
  • Flexible plan and scope
  • No quality tools usage due to scope changes
  • Business- and need-driven project
  • Time-driven schedule
Execution
  • Extensive design
  • Longer increments
  • Detailed execution plan
  • Comprehensive scope change control
  • Contractual and scope-based procurement
  • Integration during integration
  • Large teams for execution
  • Simple design
  • Short increments
  • Iterative and reactive execution plan
  • Easy refactoring
  • Requirement-based procurement
  • Continuous integration
  • Small teams for execution
Monitoring and Controlling
  • Quantitative control
  • Documented-test plans and procedures
  • Earned value for tracking project costs
  • Weekly and monthly
  • Qualitative control
  • Executable test cases define testing
  • Frequently changing baseline
  • Simple graphic tools for reporting
Closeout
  • Systematic approach to contract closeout
  • Easy to capture lessons learned
  • Explicit and tacit-based lessons learned
  • Lack of guidelines (terms and conditions)
  • Difficult to capture lessons learned
  • Tacit-knowledge intensive lessons learned

Summary of Literature Review

Agile project management methodology is commonly used for software development projects. It has greater adaptability to frequently changing scope. As a consequence, agile project management uses iterative or phased planning and continuous integration throughout the life of the project. The key principle in agile project management is to keep the project scope soft. Agile project management method is different from a traditional project management method by assigning importance to factors that are traditionally considered unimportant. Agile assigns relatively higher importance to:

  • Individuals and interactions over processes and tools
  • Project execution over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Response to change over a project plan

The agile method emphasizes flexibility to meet project needs. Further, it relies on customer feedback to initiate changes to a project plan. The methodology uses the approach of identifying the appropriate end users and their goals to formulate project deliverables and to meet the performing needs of the business processes. Advantages of using the agile method include increased customer satisfaction, lower defect rates, and faster development times. Additionally, the agile method is an answer to rapidly changing requirements, as it uses early feedback on technology features of project deliverables. The agile method ensures that requirements are not crammed. Key features of the agile method are effective communication within and outside the project team, and demonstrated flexibility in adding more requirements.

These benefits would help organizations provide better customer service. Further, they are relevant in the present economy where globalization and a free marketing philosophy are affecting the perceptions of the customers in raising expectations to deliver products and/or services faster, cheaper, and better.

However, the agile method is not without shortcomings, as can be seen in Table 1. Frequently changing scope leads to difficulty in monitoring project progress. Also, it is not easy to capture tacit knowledge in the form of lessons learned. Scope change control, documentation, comprehensive plan, quality management, and risk management are important benefits of traditional project management that we can be deprived of when employing agile method.

Research Methodology

We used both personal interviews and questionnaires to collect the data. We developed a structured questionnaire consisting of two sections. The first section was designed to capture details about the project and its characteristics. This section consists of 13 questions, which are related to project demographics and project management practices. They were presented to the participants of the study with an option to provide open-ended responses when necessary.

The second section focused on project management practice statements, and participants were asked to respond to these statements on five-point scale with 1 denoting “strongly disagree” and 5 denoting “strongly agree.” The following statements were used addressing important common tenets of project management practices, as well as serving to contrast traditional and agile project management practices.

  • The criteria for measuring project success are based on the project's objectives and goals.
  • The project is driven by requirements.
  • The project is adaptable to change.
  • In your opinion, project management efforts achieved expected results
  • Face-to-face interactions and shorter communication chains are given more importance than processes and tools.
  • Team focus is on project execution over comprehensive documentation.
  • Customer collaboration over contract negotiation works better for your team.
  • The project has a well-defined project scope.
  • Project management practices follow the PMBOK® Guide project life cycle.
  • Iterative or phased project planning is followed for the project.
  • The project has documentation requirements such as adherence to standards like ISO9000, OMB 300.
  • User Acceptance Testing (UAT) procedures are followed throughout the project.
  • The project manager is empowered to make project-related decisions without customer intervention.

Responses to these statements are analyzed in conjunction with the appropriate questions from the first set of 13 questions. Together, responses to both sections provided detailed understanding of the project for meaningful analysis.

Study Results

The questionnaire was structured to capture data on 20 IT consulting projects, which were in progress at the time of the research. Of the projects, 65% are time and material contract type projects and the remaining are firm fixed price (FFP) type. Among the time and material projects, 55% have a project duration of more than two years.

Most of the project teams are small: only 15% have 10 or more members. With respect to communication among the project team members, 60% of the respondents have used only formal communication for project needs; 30% used both formal and informal communication, and the remaining 10% relied on informal methods alone.

One out of two respondents indicated that their projects have used a project plan. In a related question, of those projects that did not have a project plan, 80% did not use iterative planning either.

Scope change is an important aspect of this study. Of the projects, 70% have experienced scope change at least once. Of those that experienced project scope change, 60% experienced it more than twice. While the client decides the scope change, the consultant—with the consent of the client—can include the quality control plan in the project management plan. When asked whether they have a quality control plan for their project, 65% of the respondents indicated they did not use a quality control plan.

Results Discussion and Analysis

Research results were analyzed by carefully examining any interrelation between a question and all other questions first to validate results and second, to develop effective management strategies. Additionally, these results were analyzed with a view to examine which agile and traditional project management practices can be used in combination to develop a robust project management approach for IT consulting projects.

Project Success Criteria Based on its Objectives and Goals

A project is considered successful when it meets its objectives and goals. Only 60% of the respondents agreed with the statement, “The criteria for measuring project success are based on the project's objectives and goals.” About 30% of the respondents disagreed. Further analysis has shown that the reason for disagreeing was that these projects were experiencing constant changing conditions and requirements, or the client was not clear about the project. Ultimately, these projects were experiencing frequent scope change. In one particular instance, the project goals and objectives changed.

It is interesting to note that there is no association between the fact that a project's success criteria are derived from its objectives and scope change, type of project, and the existence of a project plan. In other words, deriving project criteria from the organization's strategic plan has no bearing on scope change and whether the project has a plan.

Project Requirements

Usually, a detailed project plan is developed after the project sponsor's requirements are clearly identified. Project plan development and its execution, in principle, should be driven by these requirements. Therefore, one would expect that project managers would agree with the statement, “The project is driven by requirements.” Study results show that only 60% of the respondents said that their projects are driven by requirements. About 20% of the respondents who disagreed with the statement indicated that their projects are executed without using a project plan.

About 20% of the respondents who were neutral in response to this statement are the project managers who did not experience any scope change in their projects. All other respondents, those who agreed or disagreed with the statement, have experienced scope change at least once in their current projects.

In general, if a project is not implemented according to its plan, we may assume that requirements are not identified or project requirements are expected to change during its execution. In this study, however, we cannot establish such an association between “implementing the project without using the project plan” and the “the project is not driven by requirements,” because only 50% of those who agreed with the second statement have also managed projects without using a plan.

Adaptability to Change

Eighteen out of 20 projects have responded to changes in the project successfully. Adaptability to change is considered a primary characteristic for a project to be a candidate for using agile project management methodology. IT consulting projects represented in this study have demonstrated that they have adaptability to deal with scope change.

Project Management Efforts Achieved Expected Results

Results suggest that the client is satisfied with the outcome in the majority of the projects (70%). However, these responses were not associated with responses to other important survey questions about the project progress and product developed from the project manager's perspective. Reasons are obvious. Projects were still experiencing time and cost overruns. While the end result in delivering the software product is satisfactory, project management processes were not executed successfully. The inference could be that adopting traditional project management practices such as developing milestones, monitoring, and controlling would have helped manage the project successfully.

Importance of Face-to-Face Communication versus Processes

Communication is the key to understanding roles, responsibilities, policies, and procedures related to projects, and encouraging collaboration. Ultimately, communication leads to a cohesive project team and encourages team members to collaborate and participate in decision-making. Seven out of ten project managers who participated in the study agreed that face-to-face interactions and shorter communication chains were given more importance than processes and tools.

Results show a strong association between the importance of face-to-face communication and the means of communication among the project team members. Those who disagreed that face-to-face communication is more important than project processes have used informal communication among the project team members, whereas those who considered face-to-face communication to be more important have used both formal and informal communication.

Focus on Project Execution Over Documentation

Project documentation is often overlooked and consequently, organizations are deprived of important lessons learned in project planning and execution. Considering that all the projects represented in this study are federal government projects, it is interesting to note that 70% of the responding project managers agreed that their teams focused on project execution compared to creating comprehensive documentation. In a few cases where project managers have considered that documentation is more important than project execution, further investigation revealed that the customer was indecisive about the project in all those cases.

Customer Collaboration Over Contract Negotiation

Contract negotiation is an essential feature of external projects. During the negotiation, both parties would focus on protecting their self-interests. Negotiating the contract can take place at different stages of the project. It is desirable to deal with these issues through collaboration, specifically during project implementation; otherwise, it will lead to problems such as extension of the contract. Given that all the projects represented in this study are contracts, it is heartening to note that more than half of the responding project managers (60%) consider customer collaboration to be more important than contract negotiation. They suggested that collaboration works better for project teams.

Where there was disagreement, implying that collaboration is not as important as negotiation, two interesting facts were associated with those projects. All other projects used direct contact as a means of communication with the project stakeholders, but these projects used chain-of-command communication and the customer was also indecisive about the project. Both these factors imply difficult conditions for collaboration.

Project and a Well-Defined Project Scope

Projects are usually associated with uncertainties and unknown factors, which lead to ambiguity. As a consequence, detailed scope and specifications cannot be developed during the early phase of the project. The scope of the project continually changes throughout the project. Sometimes, original objectives of the project may also change. Of the projects surveyed, 40% have well-defined scope, while another 45% did not.

However, 80% of the projects experienced scope change at least once, which validates the arguments previously presented.

Project Management Practices and the PMBOK® Guide Project Lifecycle

The PMBOK® Guide has developed an elaborate project management life cycle process; it is exhaustive and comprehensive. However, it is not necessary that every process of the PMBOK® Guide project management life cycle be applied to every project. Its adoption should be project-specific. As expected, 45% of the project managers followed the project management practices of the PMBOK® Guide project life cycle, and another 45% did not.

Iterative or Phased Project Planning

Scope definition and project management plan are part of the project plan. As discussed earlier, detailed development of scope and specifications cannot be developed early in the project. Consequently, the scope of the project continually changes throughout the project, which underlines the importance of iterative or phased project planning, an important characteristic of agile method. When asked whether iterative or phased project planning is followed for the project or not, half of the respondents indicated yes, and only 15% did not follow iterative project planning. It is interesting to note that all those who disagreed with the practice of iterative project planning did not have a project plan in the first place.

Documentation and Adherence to Standards

Project documentation serves as a reference for analysis of historical data and helps organizations continuously improve project management processes and develop standards. The documentation will also help to identify lessons learned and to modify project management systems that will lead to project management maturity. OMB300 and ISO9000 serve as guides in designing project documentation systems. Specifically, many government projects are required to adhere to OMB300 guidelines. Of the respondents, 80% said that the IT projects they were managing had documentation requirements such as adherence to standards like ISO9000 and OMB300. However, these requirements for the IT consulting projects are applicable to a limited extent.

User Acceptance Test Procedures

Customer satisfaction is the primary measure of quality and success for project deliverable items. Therefore, user acceptance test procedures are considered important. Even in the case of less tangible project deliverables such as service, the underlying measure of project success is customer satisfaction. However, it is subjective. Only 30% of respondents said they followed user acceptance test procedures throughout the project, and 45% of the respondents did not.

Empowerment to Make Project-Related Decisions

In general, project managers should be given a free hand to make project-related decisions without customer intervention, when these decisions do not have any major impact on the project scope or project deliverables. Only 15% agreed that the project manager is empowered to make project-related decisions without customer intervention. About 40% remained neutral, and the remaining 45% said the project manager did not have this power. Given that these projects are external and government projects, these results make sense.

Conclusion

Our study results show that the majority of the projects are driven by requirements. Almost all the projects represented in this study demonstrated that they are adaptable to change. Informal communication is considered more important than formal processes and systems. Considering that projects in the study are related to government work, results show the project team focused on project execution over comprehensive documentation. Additionally, customer collaboration over contract negotiation works better for project teams. Frequent project scope change signifies the importance of iterative or phased project planning; an important characteristic of agile project management. Given that all the IT consulting projects represented in this study are contracts, study results encourage formally adopting agile methodology for IT consulting projects and combining them with traditional project management practices such as plan-driven milestone development and monitoring, user acceptance procedures, and quality management practices.

The suitability of the agile method for projects is contractual obligation related to documents concerning project planning, monitoring, and control. Projects associated with the federal government usually have significant documentation requirements, such as adherence to standards like ISO9000 and OMB300; we should exercise caution in modifying the agile method for such projects.

The challenge is to maintain the agility, the rapid response to change, flexible and simple plans, continuous integration, and other benefits of the agile method while incorporating some of the comprehensive processes of traditional project management practices.

References

Abrahamsson, P., Warsta, J., Siponen, M., & Ronkainen, J. (2003). New directions on agile methods: A comparative analysis. Proceedings of the 25th International Conference on Software Engineering (ICSE'03), IEEE Computer Society.

Anantatmula, V. (2006). Modeling enablers for PM success. Invited speaker at the Project Management Institute North Carolina Chapter, October 26, 2006, Durham, NC.

Anantatmula, V. (2006). Improving project performance through leadership and technology. Presented at the Project Management Institute Research Conference, July 16–19, 2006.

Boehm, B. (2002). Get ready for agile methods, with care. Computer, January 2002, 64–69.

Boehm, B., & Turner, R. (2003). Observations on balancing discipline and agility. Proceedings of the Agile Development Conference (ADC'03), IEEE Computer Society.

Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. IEEE Computer Society, 57–66.

Constantine, L. (2001). Methodological agility. Software Development, June 200, 67–69.

Coram, M., & Bohner, S. (2005). Impact of agile methods of software project management. Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'05), IEEE Computer Society.

Hanakwa, N., & Okura, K. (2004). A project management support tool using communication for agile software development. Proceedings of the Asia-Pacific Software Engineering Conference (APSEC'04), IEEE Computer Society.

Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, November 2001, 131–133.

Ilieva, S., Ivanov, P., & Stefanova, E. (2004). Analyses of an agile methodology implementation. Proceedings of the Agile Development (ADC'04), IEEE Computer Society.

Karlstrom, D., & Runeson, P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 43–49.

Little, T. (2005). Context-adaptive agility: Managing complexity and uncertainty. IEEE software, 28–35.

Little, T., Greene, F., Phillips, T., Pilger, R., & Poldervaart, R. (2004). Adaptive agility. Proceedings of the Agile Development (ADC'04), IEEE Computer Society.

Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., May, J.; Kahkonen, T.(2004). Agile software development in large organizations. Computer, 37(12), 26–34.

McGovern, F. (2002). Managing software projects with business-based requirements. IT Pro, September/October, 18-–23.

Miller, S. (2005). Adapting agile approaches to your project needs, IEEE Software, 22(3), 17–20.

Melnik, G., & Mauer, F. (2004). Direct verbal communication as a catalyst of agile knowledge sharing. Proceedings of the Agile Development (ADC'04), IEEE Computer Society.

Patton, J. (2003). Unfixing the fixed scope project: Using methodologies to create flexibility in project scope. Proceedings of the Agile Development Conference (ADC'03), IEEE Computer Society.

Rad, P., & Anantatmula, V. (2005). Project planning techniques. Vienna, VA: Management Concepts.

Sauer, T. (2003). Using design rationale for agile documentation. Proceedings of the Twelfth International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE'03), IEEE Computer Society.

Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development, IEEE Software, 22(3), 36–42.

Williams, T. (2005). Assessing and moving on from the dominant project management discourse in the light of project overruns. IEEE Transactions of Engineering Management, 52(4), 497–508

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.

© 2008 Project Management Institute

Advertisement

Advertisement

Related Content

Advertisement

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