PLUS: A Project Life Cycle Use Scale

Need a simple project management software to manage your team?
Check-out our valuable and unique Top 15 Web Applications 2017.

Sometimes controversy arises in organizations that do not have a project management office or governance establishing project management methodologies. The controversy is the result of simply not knowing what should be done; the team creates direction based on uncertainty. Unfamiliarity with best practices and the guardian principles in project management naturally leaves teams to follow whatever direction feels most comfortable or less threatening. Those comfort methods, although potentially not within the recommendation of trained project management practitioners, may not be detrimental to the project. However, intentional or unintentional misalignment with what the project management community has tested and proven to produce best results is risking unnecessary stress on the project team or, worst case, manufacturing a direct line to an undesirable end to the project. It stands to reason that organizations would desire to follow proven methods for the sake of reducing internal strife, minimizing risk, and improving chances of success.

There are scores of articles that suggest reasons for project failure (Gulla, 2012) (Mulcahy, 1999) (Kogekar, 2013). These reasons are numerous and vary with every organization and situation. We have all seen the list: senior management failures, unrealistic schedules, change impact, miscommunication, lack of risk management, complexity, weak ownership, absent governance, scope creep, shallow visibility, inadequate planning, and limited resources. And to reinforce the anecdotal evidence, many academic studies support and confirm what is being witnessed in the office (Abbasi, Wajid, Iqbal, & Zafar, 2014) (Matta & Ashkenas, 2003) (Frese & Sauter, 2003).

One factor less commonly mentioned but yet has a profound impact on the outcome of a project is the selection of the project life cycle. As we know, the project life cycle is essentially the framework upon which the project is supported and the path which the project travels from idea to finished product. The idea that an organization would choose to organize and sequence work with the objective of transforming that work into a finished product is by definition what uniquely distinguishes projects from non-projects. (Wideman, 2004) It is important, therefore, to be deliberate when making the decision of life cycle type.

The project life cycle practiced for any particular project within an organization is often and instinctually a choice based on comfort level or breadth of experience. Perhaps the manager previously had success with one type of life cycle method and from that point on chooses to adopt it in every situation. It feels familiar and comfortable. However, this approach often proves regretful because project life cycles are not a one-size-fits-all formula. Indeed, a miscalculation in the chosen life cycle can cause frustration, over-work, re-work, time delays, cost overruns, or even outright failure.

Choosing a project life cycle is a decision about how the project will flow among the process groups: initiating, planning, executing, monitoring and controlling, and closing. It is one of the first and most critical decisions for the project manager. The fundamental question to be answered is, “What is the nature of the project: predictive, iterative, or adaptive?”

Throughout the course of the project it is important to understand that very few project environments require a purist approach to life cycle modeling and execution to be successful. That is to say that even if a project life cycle has been identified, success can be achieved using methods from more than one life cycle type.

In some industries one type of life cycle may be predominant but maybe not pure. For instance, construction projects are mostly predictive; the goals, objectives, and scope are to a greater degree established at the beginning of the project. However, the KSCE Journal of Civil Engineering has been studying the use of adaptive methods. (Ebrat & Ghodsi, 2014) We see here that in even the most obvious settings there is still room to investigate and incorporate methods from other life cycles.

Similarly, in the world of software development where adaptive or iterative practices are becoming the norm, it is difficult, polarizing, or even threatening to suggest any tenants of a predictive model, even in situations when the end product is highly predictable. For all the good that has resulted from the use of Agile methodologies, it is a system which is constrained by velocity. Business leaders remain frustrated that software development teams still can’t delivery at an acceptable rate or within the required business timeline, defeating the reason Agile methodologies were adopted in the first place. (Ramel, 2013)

Perhaps the answer to the best approach is in the creativity and innovation of project managers. Maybe the answer is to become more pragmatic through the application of hybrid life cycle models. (Rothman, 2007) This idea does not suggest an anything-goes environment. Every project needs a foundational structure or sure disorganization will very likely follow. Therefore, selecting a primary project life cycle framework is the first and most important step. But, this initial selection should not be the final word.

After the primary life cycle selection, the process of learning and adjusting begins. These adjustments should be focused on delivering business expectation while still maintaining team discipline and output quality. Monitoring the progress of the project team and keeping in constant communication with the business stakeholders is essential.

Decision Scale

One way to discover the primary life cycle is through the use of a measured decision scale. The one introduced here uses a linear scoring system. Core criteria identify the primary considerations as described in the next section. This is intended to be used only as a guide.

The benefit of using such a scale is to introduce a specifically designed and structured model as only one input of the decision making process. It is by design a means of producing an unbiased input to the process. If the project manager can negotiate a team agreement that such a tool is a less biased input, it will help create stronger cooperation and less stress among stakeholders and project team members throughout the course of the project.

As eluted to earlier, environmental factors should also be considered. Sometimes an organization is not familiar or has never used the chosen type of life cycle. Maybe influential leaders within an organization are resistant to new or different ideas. In any organizational challenge to adopt new practices, carefully consider additional communication, educational opportunities, and other means of soliciting cooperation.

Core Criteria

The core criteria are common characteristics found in every life cycle model. (Project Management Institute, 2013) For the purposes of this scale they are described as follows:

  1. Early Scope Determination. This criterion determines if the final outcome of the project can be well defined and understood in detail before the work begins. The final outcome of the project should be defined to the greatest amount of detail as possible as early on in the project as possible no matter the life cycle type. The final outcome is described in terms of goals, objectives, and scope. If it is knowable then it can be and it should be found out within acceptable planning time constraints. The development of the final outcome should involve all key stakeholders and it should be well communicated and commonly understood. If the final outcome can be only generalized and cannot be known in detail until after the project has progressed into the actual execution, then the level of certainty about the final outcome may not be able to be determined; it may not be knowable.
  1. Allowance for Change. This criterion determines if the odds of changes being allowed to interfere with the on-time and on-budget delivery of this project are low. Determined leadership can prevent all but the most critical change requests from interfering with the on-time and on-budget delivery of the project. However, some projects may not have a well-defined scope until very near the end of the project due to the volume of things unknowable. In this case, changes are intentionally allowed as a byproduct of customer feedback during execution in order to arrive at the most achievable and acceptable product or service within a given timeframe.
  1. Project Complexity. This criterion determines if the project is complex. Complex projects are those that have many interrelated details. These details require a considerable amount of time to fully understand, are difficult to execute, or the scope of the project requires a large team to execute. If any of these conditions are met the project may be complex.
  1. Knowledge Base Availability. This criterion determines to what degree the team has experience executing the project or if the team has access to a substantial knowledge base of industry best practices regarding the project. The more familiar and experienced a team is at executing a particular type of project, the more predictable the scope, risks, costs become. Alternatively, if the team is not experienced but has access to a substantial knowledge base of industry best practices, this can have a significant impact on predicting the course of the project.
  1. Partial Delivery Value. This criterion determines the level of customer satisfaction or business value if the project were partially delivered. Providing value to the customer or business is the goal of any project. If a project needs to be delivered in whole in order for it to have value, it will require almost all planning be done in the beginning of the delivery cycle, before execution or development begins. It is important to note that this is almost entirely the determination of the customer, not the service or product developer.

Instruction to Survey

  • First, for each of the Core Criteria Survey statements select the answer that best describes your agreement with the statement and record each answer.
  • Second, use the Scoring and Interpretation section to determine the total score and the corresponding recommended project life cycle option.
  • Finally, consider the environmental factors. Determine if there are any factors that may limit the organization from adopting and implementing the chosen life cycle. Create a plan to overcome objectives.

Core Criteria Survey

  1. The final outcome of the project can be well defined and understood before the work begins.
    1. Strongly disagree
    2. Somewhat disagree
    3. Somewhat agree
    4. Strongly agree
  2. The odds of changes being allowed to interfere with the on-time and on-budget delivery of this project are low.
    1. Strongly disagree
    2. Somewhat disagree
    3. Somewhat agree
    4. Strongly agree
  3. The project is not complex.
    1. Strongly disagree
    2. Somewhat disagree
    3. Somewhat agree
    4. Strongly agree
  4. The team has experience doing this project or the team has access to a substantial knowledge base of industry best practices regarding this project.
    1. Strongly disagree
    2. Somewhat disagree
    3. Somewhat agree
    4. Strongly agree
  5. If the project is partially delivered the customer will be dissatisfied and see no or low benefit or value.
    1. Strongly disagree
    2. Somewhat disagree
    3. Somewhat agree
    4. Strongly agree

Scoring and Interpretation

Answer Values

A = 1, B=2, C=3, D=4

Score Interpretation – Recommended Project Life Cycle Option

Add the score of all five answers and match the result with the following:

  • A total score of 5 suggests an Adaptive project life cycle should be used (Change Drive, Agile).
  • A total score between 5 and 10 suggests a hybrid of Adaptive and Iterative/Incremental project life cycles should be used.
  • A total score of 10 suggests an Iterative/Incremental project life cycle should be used.
  • A total score between 10 and 20 suggests a hybrid Iterative/Incremental and Predictive project life cycles should be used.
  • A total score of 20 suggests a Predictive project life cycle should be used (Fully plan-driven).

Next Steps

One should become familiar with practices and methodologies associated with each type of project life cycle before implementing. It is beyond the scope of the article to review these practices. However, a great primary resource for this information is The Project Management Institute. They have a comprehensive library of very helpful material.

Making projects more successful begins with a good foundation which includes a life cycle that has been purposely selected. Implementing a scale like PLUS can help in that decision process.

References

Abbasi, N., Wajid, I., Iqbal, Z., & Zafar, F. (2014). Project Failure Case Studies and Suggestion. Internaional Journal of Computer Applications, 86(6), 34-39. Retrieved from http://research.ijcaonline.org/volume86/number6/pxc3892696.pdf

Ebrat, M., & Ghodsi, R. (2014). Construction project risk assessment by using adaptive-network-based fuzzy inference system: An empirical study. KSCE Journal of Civil Engineering, 18(5), 1213-1227.

Frese, R., & Sauter, V. (2003, December 16). Project Success and Failure: What is Success, What is Failure, and how can you Improve Your Odds for Success? Retrieved from University of Missouri-St. Louis: http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/frese/

Gulla, J. (2012, February). Seven Reasons IT Projects Fail. Retrieved from IBM Systems Magazine: http://www.ibmsystemsmag.com/power/Systems-Management/Workload-Management/project_pitfalls/?page=1

Kogekar, H. (2013, December 5). Why IT Projects Really Fail. Retrieved from CIO: http://www.cio.com.au/article/533532/why_it_projects_really_fail/

Matta, N. F., & Ashkenas, R. N. (2003, September). Why Good Projects Fail Anyway. Harvard Business Review.

Mulcahy, R. (1999). Top Reasons Projects Fail. Retrieved from Project Management Institute: http://www.pmi.org/learning/library/top-reasons-projects-fail-1124

Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge – Fifth Edition. Newtown Square, Pennsylvania: Project Managment Institute Inc.

Ramel, D. (2013, March 15). Forrester Study Reveals Disconnect Between Business and Software Development. Retrieved from ADT Mag – Application Development Trends: https://adtmag.com/articles/2013/03/15/forrester-report-on-business-disconnect-with-software-development.aspx

Rothman, J. (2007). Manage It! Your Guide to Modern, Pragmatic Project Management. Pragmatic Bookshelf.

Wideman, M. R. (2004, February). The Role of the Project Life Cycle (Life Span) in Project Management. Retrieved from Max Wideman: http://www.maxwideman.com/papers/plc-models/plc-models.pdf

David Ashley

David Ashley

David Ashley is a 20-year US Air Force veteran with 15 years in the private sector. Currently David is a program manager at a Fortune 500 company. He is a Summa Cum Laude graduate of Colorado Technical University with a B.S. in Project Management and maintains his PMP credential.

Leave a Reply