Author: Ronald B. Smith, MBA, PMP

Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.

Project Portfolio Selection Using NPV (Part 2)

Project Portfolio Selection Using NPV (Part 2)

Turning the whole system into something greater than the sum of its parts   In the first part of my article, we covered how the selection of projects is crucial to Project Portfolio Management (PPM), and we saw firsthand, by looking at a few case specific scenarios, how true this is. But, what about the financial formulas available in MS Excel and Project? Let’s consider how they play into this analysis.   Microsoft Excel and Project Excel has many great financial formulas (i.e., =XNPV(rate,values,dates)) that are easy to use and should be used as tools for project portfolio selection. Two formulas that are related, but just “estimates” are XNPV and XIRR (or Internal Rate of Return). You must be careful when you use them, so you are not misled. As I said, they are just estimates. The main difference between the two is that XNPV calculates the value of the business today, and XIRR calculates how fast the business or rate appreciates in value (i.e. its rate of return).   Microsoft Project interfaces with Excel (and Visio) offering many different kinds of visual reports showing financial information in bar graphs, pie charts, and/or line graphs. These can be very useful in project status meetings. To generate these reports in Project, go to the Report tab’s Export section and then click Visual Reports. The financial Excel reports include: baseline cost, cash flow, earned value over time, and resource cost summary. Furthermore, these reports can be customized as needed and saved as Excel files.   There are three main NPV categories (Revenue, Operating, and Competitive Necessities) that you will find below in selecting what projects to work on, and these should be listed in Project’s first line (WBS = 1) under Notes. To do this, right click the first line, select Information and the Notes tab, and copy/paste the selected project’s NPV Excel data in it. I recommend doing this for historical reasons (i.e. why this individual project was selected) so that you’ll be able to provide evidence in legal proceedings, if needed. Additionally, you can later test your cost/NPV selection process to see if it’s correct or needs tweaking. See Table 1.7 below for an example.   Table 1.7: Why Project 2 was Selected   NPV Categories Revenue Necessity: This refers to selecting projects (from Table 1.6) that have the highest Profitability Index. Most companies want to decrease costs and increase revenues as much as they can.   Operating Necessity: Sometimes an organization has to go against its formal project decision-making process because of external or internal factors. For example, Tables 1.4, 1.5, and 1.6 have the same ten projects that were prioritized and showed the best projects based on their own selection criteria. Let’s say project 10, which was not selected in Tables 1.5 and 1.6, is a new mandated U.S. federal law like the Sarbanes-Oxley Act or the Dodd-Frank Act (both related to corporate compliance on financial regulations). Of course, because of the nature of the project, this one needs to be incorporated into your operations.   This means that you would use your selection criteria on the first nine projects. In a different scenario, let’s say Project 10 has been approved (another free-pass) by your board of directors and/or CEO to improve the company’s public image, which may be at a very low point. In this case, again this project would have to be implemented, which means you would use your selection criteria on the first nine projects. Other “free-pass” projects may include advoiding litigation, addressing regulatory issues, and reducing exposure.   Competitive Necessity: These projects are similar to Operating Necessity projects, but are less critical. Competitive Necessity projects are usually in response to a competitor’s actions or a change in technology or markets that could lead to a new strategy for the organization. For example, computer hard drive manufacturers had to upgrade their manufacturing facilities to change from making hard disk drives (HDD) to making storage area network (SAN) drives. The long-term benefits and savings for their customers were great! The devices took up less than half the rack storage space versus using HDD, time to access data was cut in half, and the data transfer rate doubled. Likewise, if project 10 from Tables 1.5 and 1.6 is an approved competitive one, then you would use your selection criteria on the first nine projects.   Other Financial Decision Considerations Payback Period: Capital budgeting refers to the period of time required for the return on the entire investment if the returns are evenly distributed over the years with little or no salvage value. Assume an investment of $500,000 is expected to produce annual returns of $100,000 for ten years. Then, the payback period for the investment to be recovered would be five years. The ratio of the investment to the annual return is 5:1. Expressed in another way, the unadjusted rate of return is 20% as follows: the $100,000 returns is divided by the $500,000 investment, which equals a 20% rate of return. As anyone should see, the math is simple to follow, but the payback period has some drawbacks. For example, it ignores cash flows after the payback period ends and ignores the time value of money. NPV does take into account the time value of money (i.e. the net cash flows at different points in time), which gives a more accurate picture of financial performance.   Depreciation and Income Tax: Organizations may need to acquire capital assets that are depreciable for income tax purposes over a period of accounting periods. Assume a new host computer costs $500,000 with a life expectancy of five years with no trade-in or resale value at the end of five years. The annual tax deduction for depreciation would be $100,000 ($500,000/5) for five years. If there is a trade-in or resale value at the end of five years of $100,000, then the annual tax deduction for depreciation would be $80,000 (($500,000 – $100,000)/5). The possible tax effect of depreciation must be considered when making investments especially when depreciation deductions will reduce annual cash out-flows by paying less income tax.   Reducing Risks: One of the main keys to PPM is to diversify investments in such a way as to reduce the overall risks within a portfolio. While it’s important to optimize the total financial value of projects within a portfolio, you still want to minimize the risk exposure by having early and frequent risk reviews for each project. Also, it’s important to be aware of your external risks (i.e. customers, suppliers, competitors, industry, and economy) and internal risks (i.e. resource estimations, schedule estimations, scope definitions, and scope creep). As one can see, reducing risks is part of portfolio balancing and optimization that should be done on a regular basis. It’s important to always remember some things will go wrong in pending and approved projects within an organization. Of course, it’s easier and faster to expect such issues and have a plan for how to respond.   Summary Many companies still use unscientific approaches when it comes to PPM evaluation and selection. These approaches usually lead to wasted monies, resources, and unfavorable politics. Having formal methods for portfolio evaluation and selection, such as those described in this article, will go a long way for your organization and help to eliminate much of the political flavor in project selection. PPM should improve your project selection process, give you a better understanding of project value, and could help you obtain funds for a project. As much as possible, you should always want to pick projects and programs that meet your organization’s strategic goals. Be aware that many companies’ strategic plans are more like mission or vision statement than a road map, and very few companies do “post audits” that could confirm whether investments actually paid off. Even if a post audit showed negative financial outcomes, it might expose a manager’s data gathering errors and manipulation efforts.   It’s important that portfolio managers have solid financial and analytical skills and understand how projects and programs can increase NPV (or other selected financial formulas) while supporting strategic goals. Furthermore, portfolio managers might consider getting certification through PMI as a Portfolio Management Professional (PfMP) to increase their skill level and/or future opportunities. There are only about 400 holders of this certification, and in my opinion, there should be more. Another PMI certification to consider, one of which there are about 2,000 holders, is the Program Management Professional (PgMP) certification.   Since the PPM approach is not a “one-size fits all” solution, your organization should research other optimization methods and models for PPM evaluation and selection to find their best value equation. This could include integer linear programming that will maximize or minimize some target area, what-if-modeling, and/or software that shows inter-project dependencies to understand what is going on in other projects. All of these considerations will lead to better resource allocation. Most of these features can be found in project-portfolio software products like Microsoft Project Portfolio Management (microsoft.com) or Primavera Enterprise Project Portfolio Management (oracle.com). Some of the functionalities include staffing projects from a common resource pool and tracking activities on multiple projects to show inter-project activity dependencies. More importantly, these tools can assist in the selection of the right mix of strategic projects. Another advantage to having this kind of software is having common project communications (i.e. tracking reports and accomplishment reports). This common language fosters team collaboration throughout the organization by promoting well established project-management and data-oriented policies, processes, and procedures.   The people running PPM need to learn to communicate better to build trust and to insure their messages are clear and understandable within their organization. Communication management should always include rich visual dashboards that have hyperlinks to allow people to drill down on their own time to see more detailed information. These dashboards (i.e. pie charts, Gantt charts, and status indicators) will help a PPM to deliver status information in a precise and timely manner.          

Project Portfolio Selection Using NPV (Part 1)

Project Portfolio Selection Using NPV (Part 1)

Turning the whole system into something greater than the sum of its parts   A crucial part of Project Portfolio Management (PPM) is the selection of projects. This is an ongoing dynamic process. In the following two part article, I will be demonstrating Net Present Value or NPV. PPM is simply managing your company’s resources. It has less to do with project management skills and more to do with strategic planning. In selecting projects, you want to pick the ones that create the greatest return and contribution to the strategic interests of your organization within the confines of your annual budget. Going a step beyond, you really want to optimize the portfolio and turn the whole system into something greater than the sum of its parts. Think of it this way – if each project is an instrument in your company’s orchestra, then you have programs made up of wind, percussion, and string instruments. You want someone – the conductor – to enhance the whole system by having the technical skills, leadership skills, and respectability to lead the orchestra in creating beautiful music. See Table 1.1. In many ways, PMs and musical conductors have common denominators. For example:   They have the capacity and desire to lead/guide their project teams or musical ensembles. This includes cooperation and networking.   They have to be good communicators. Besides verbal communication with their orchestras, conductors also communicate through hand gestures, typically with the aid of a baton, which means they need to be in good physical shape! So should PMs for that matter.   They are involved in bringing talent together and scheduling activities.   They have to interpret the overall project plan or musical scores.   They have a rehearsal process. That is, to review work-in-process plans or practice musical scores. Practice makes perfect!   They have to satisfy their customers. Whether users/stakeholders or audiences, hopefully the customers are happy people!     Projects, Programs, and Portfolio Differences Throughout my career working with many users and executives, I have learned there is a lot of talk about projects and portfolios, but not much reference to programs. Many times I have been assigned a “project,” analyzed the endeavor, and realized that in actuality it was a group of three to five related projects. When I gave status updates, I always used the term “program,” although quite frequently the users and/or executives would call my endeavor a “project.” It always bothered me. What I got from this was that they really didn’t know the difference between a project and a program, or they did, they just didn’t care about the semantics (the whole “just get the darn job done!” mentality). Before I get into project portfolio selection, it’s important that we cover the differences between projects, programs, and portfolios.   Portfolio managers (PfM) balance conflicting demands between programs and projects and manage them to achieve the anticipated benefits. Program management (PgM) focuses on achieving the cost, schedule, and performance objectives of the projects within the program or portfolio, while project management (PM) is largely concerned with achieving specific deliverables that support specific organizational objectives. The Standard for Portfolio Management – Third Edition (Project Management Institute, 2013c) documents the attributes, differences, and coincidences among the three (3) types of practices as follows (Table 1.2):     Prioritized Project Portfolio Everyone would like to have a prioritized project portfolio that holds maximum value over a specific time period, but there are many variables (i.e. having enough money and sufficient resources with the right skills) to be considered. The key goals of the portfolio optimization process are to align project work with the strategic direction of the organization, maximize the value of the portfolio, and to balance the project portfolio. The following NPV financial case studies will hopefully provide us with the insight we need to improve a portfolio from a solid one to a much more profitable one. NPV is one of the most widely used financial attributes because it measures the financial return of an investment, which uses external factors like inflation, investment risk, and cost of borrowing money.   Case 1: Maximizing NPV Let’s say the Fit-It company has a portfolio of ten new proposed projects (see Table 1.3) that require a total cost of $5 billion and could yield $11 billion for NPV. Regrettably, the company is constrained by its annual budget of $3.5 billion and needs to determine which projects to fund to maximize its potential. The first step is to rank or sort the NPV column (see Table 1.4) to find out how far we can go down the list until we run out of budget. We can afford five projects (5, 4, 10, 1, and 3) for a budget of $3.420 billion yielding a portfolio NPV of $7.150 billion.       Case 2: Optimizing NPV The previously described case study is certainly feasible as far as portfolios go, but it may not be optimal. In fact, we may be able to create a better portfolio getting supreme value from the company’s annual budget of $3.5 billion. Using optimization software (developed in-house or purchased), we search for the most efficient portfolio. Optimizing software uses many variables, such as risk, budget, people, current ongoing projects, and manufacturing capacity, to arrive at the best combination of projects. Table 1.5 is an example of using optimizing software (SW). The NPV from Case 1 went from $7.150 billion to currently $7.950 billion for an increased value of $800 million. The new budget of $3.480 billion almost matches the annual budget and the number of selected projects went from five to eight.     Case 3: Profitability NPV Since some executives prefer to see an annual return per project, they could look at the profitability index (i.e. Return on Investment), which is the NPV divided by the initial investment or cost to get the best combination of projects. This ratio basically gives you the biggest bang for your buck for each project. Of course, the higher the profitability index the better! I have taken the same ten proposed projects used in the previous case and ranked them by their profitability index (see Table 1.6) to get a higher NPV ($7.990 billion) than the one from the previous case described ($7.950). Also, the budget from the previous case went from $3.480 billion down to $3.450 billion, which means we saved $30 million in costs, and at the same time, increased our NPV by $40 million for a $70 million positive spread.     We will pick up next time (in part 2 of my article) by considering how the financial formulas available in MS Excel and Project fit into this analysis. I will also cover several other considerations that should be made when selecting projects for portfolio management. In the meantime, what tools do you use to make project portfolio selections?  

An Agile Attitude: Part 2

An Agile Attitude: Part 2

In Part 1, we looked at the history of Agile and the Waterfall vs. Agile model. Now, I’d like to pick up where we left off and consider how MSP is adapting to more and more organizations implementing Agile. A Short History of Microsoft Project (Or How MSP is Adapting to Agile) Microsoft Project (MSP) has been around since the mid-1980’s and started out as a DOS base project management software product that evolved into a window based product in 1990. Since then, MSP has become the dominant (over 25 million users) PC based project management product used by most organizations. The upgrade from MSP 2010 to MSP 2013 was a major one. The biggest improvement was replacing the text-based reports with graphical reports, which gave project managers an entirely a new way of visualizing project data. MSP 2013 did include an Agile Project Management template as shown in the below graphic, which is found under the File tab (click New). This template is just a starting point for adding sprints and work items, but could be your foundation for developing an Agile project plan. Figure 1.7 shows you a high-level Agile project plan that was generated by using the template from Figure 1.6 which includes resources from Figure 1.1: Agile Roles. The upgrade from MSP 2013 to MSP 2016 was minor in comparison, but did include new timeline updates. Unfortunately, when MSP 2019 came out it was another minor upgrade (e.g., choose a predecessor or successor from a drop-down list) from MSP 2016. I believe these last two updates were minor because Microsoft is focusing more on its Enterprise (i.e., Office 365) applications, as well as project server. The upgrades in MSP 2019 did include upgrades only in project online desktop client with some Agile features and integration with Microsoft Planner. Because of the fast growing popularity of Agile, future versions of MSP beyond 2019 should include many new Agile fields, features, and reports as standard items. The “Sprint” column in Figure 1.7 is a renamed or custom text field that I defined. In the same manner, you can add other Agile related fields like State (e.g., open, closed, done, in progress, or not started) and User Need (setting your priorities or ranking priorities in order of importance). Custom fields are a powerful feature of MSP, and when used with custom groups, filters, and views, you can narrow your focus to what you think is most important at any point in time. Even though Figure 1.7 displays a nice high-level Agile project plan with all the tasks, your Agile project team likely wants to see a snap-shot picture status of their sprints and features to be implemented at least every week, if not daily. This can be done within MSP using Agile-specific information in custom fields allowing you to filter or group specific data and provide different perspectives on the status of your project. All of the text-based defined fields used in Figure 1.8 are as follows: Grouping any MSP data with similar characteristics is easy to do with the Group feature found in the View tab’s Data section. There are many standard groups to choose from (e.g., Critical or Milestones), but we want to create a new group called New Group By. See Figure 1.9, which groups Figure 1.8’s States (Text12) within Sprints (Text13) This is called a Burndown and will produce Figure 1.10, which helps you to better understand and analyze your project information. Implementing APM Implementing APM in most organizations will be challenging for several reasons. Most organizations buy their software developed applications like Microsoft Office, Oracle, or SAP financials, so the main in-house project is implementing the software and training the people to use it. Approximately 25% of all projects within most IT organizations are related to software development (i.e., developing applications from Oracle) and these are usually long-term projects. As a result, the full benefits of APM are limited. This means about 75% of in-house projects are not related to software development and will usually use the traditional Waterfall approach. Insufficient training is the most significant cause for failed Agile implementations within organizations. Agile software development has a set of prescribed rules. Training and practice is required for success. Team members must let go of the idea that the product has to be 100% complete when it is delivered. They must also understand the reality that there’s no end to the Agile learning curve. In addition, creating the Agile transformation is difficult unless organizations and project leaders are truly prepared to make a shift. This could be particularly hard for large matrix organizations. Transitioning to Agile means starting in small steps and being willing to change when necessary. Furthermore, organizations will need qualified people trained in Agile to be coaches, mentors, and to help in the adoption process. An excellent way to start implementing Agile is to bring in a consulting firm that specializes in Agile methodology. Expert coaches and scrum masters can help an organization adopt an Agile strategy that’s right. Keeping the traditional Waterfall development methodology and using APM within the same IT organization or having a “hybrid” implementation organization opens the door for a lot of confusion especially in the areas of controlling projects and measuring successes. Again, this is a great culture change, but having a cross-functional development team for Agile who is committed to the change and will support your organization is vital. The Scrum Master or product owner needs to have real “clout” within an organization. Unfortunately, in most organizations, PMs (leaders) have limited “clout.” You don’t need project management experience to be a Scrum Master (sometimes called a project facilitator), but it helps if you have this background. It gives you a “leg up.” The Scrum Master (see the figure below) is a key role for APM. This person acts as a practice coach, helping the project team, protecting the team from organization distractions, clearing roadblocks, and following scrum values and practices. People assigned to an Agile project team (usually 3 – 9 in number) need to be available 100% of the time and should not be working on other projects. This core team should include the Scrum Master, Development Team, and the Product Owner (customer representative who is the expert on the product and customer needs and priorities). This is a big culture change for most IT organizations and will be difficult to achieve especially if traditional Waterfall projects are being implemented at the same time. Processes are easy, but people are hard! My advice is that APM teams should be collocated (i.e., communicating face to face as shown in Figure 1.11), which means they are working together in a dedicated office area. If a work project room or scrum room can’t be allocated, then cubicle walls will need to come down, so there is single work area for the APM team. Again this will likely be a culture change for an IT organization especially if traditional Waterfall projects are being implemented at the same time. Be ready to buck the status quo going to APM. Some people have vested interests and will be not want to change how they work. APM requires mature behavior. Accomplishments and failures alike belong to the project team and not to individuals. Furthermore, there needs to be an environment of trust and self-management. Earned Value Management (EVM) is a way of measuring project progress, but this is based on an assumed fixed project scope, whereas APM is based on accommodating ongoing scope changes by providing a constant cycle of development, feedback, and change. EVM is used worldwide for mostly large defense or government projects, and private-industry sectors such as construction, energy, and manufacturing. Note, it doesn’t make much sense to force EVM on Agile projects. Summary Agile is not a magic bullet or a cure-all that will make your project run faster than any other one. It’s a real approach with precise rules and roles. It is generally used in short-term projects where the end product is not perfectly described or known at the beginning. It isn’t a way to skip formal project follow-up and administrative management. The risk with an uncontrolled Agile approach is to deliver fewer features than initially scheduled because if, at the end of iteration, the job is not completed or if tests failed, the product scope is reduced for the next iteration to try to deliver something functional. Yes, at the end, budget and time will be respected, but forget the product. Check to see if a real and driven Agile approach is used with key players, with each one in a precise role, and if key project documentation (i.e., product backlog) is maintained. Agile is a good solution for projects that are in development or undergoing major changes with less chance of project failure. For other projects such as those in maintenance mode, Agile is not suitable, but if you are looking for rapid development and tighter project control, Agile can be a great fit for your organization. By adopting Agile approaches, you could achieve increases in product productivity and delivery. The old Agile versus Waterfall debate is fading as many companies learn to be flexible with both delivery approaches in our fast changing world. The consensus is clear – use the right approach for the right project! PMI has many certification types with the Project Management Professional (PMP) being the world-wide favorite. In 2011, PMI introduced a new certification called Agile Certified Practitioner (PMI-ACP). The number of professionals obtaining this new certification has grown dramatically (there are currently over 23,000 holders) because more and more companies are overcoming the above mentioned challenges to Agile and accepting the approach to managing projects. When you purchase the updated PMBOK® guide, Sixth Edition – 2017 (now Agile-aware), you receive a free copy of Agile Practice Guide. This guide was developed as a result of cooperation between PMI and the Agile Alliance.

Implementing Agile – Part 1

Implementing Agile – Part 1

“Implementing Agile can be challenging but rewarding“ Implementing Agile can be very challenging for many organizations (especially in Waterfall development cultures), but at the same time, it can be rewarding. This article covers a short history of Agile methodology, which became mainstream this decade to rev up software development with a faster approach. It defines Agile, its benefits, and covers techniques for using Microsoft Project for your Agile projects. Read on if you’ve ever wanted to make your transition to Agile easier. A Short History of Agile In 2001, new methodology pioneers met in Snowbird, Utah to share their experiences and to suggest ideas for improving the world of software development. They came up with the Agile Manifesto to streamline the development process. According to the Agile Manifesto (2001) : The pioneers also came up with a set of Agile principles, which were broken into four major groups: customer satisfaction, quality, teamwork, and project management. For years, most organizations were very slow in trying the Agile approach, but in the past ten years, they began to have an Agile attitude and its usage has grown exponentially. Why do you think that is? User satisfaction! According to a Standish Group Study in 2015, it was found that 29% of traditional projects failed outright and were canceled, but that number decreased to 9% for Agile projects. I believe this is a direct result of Agile teams making immediate adaptations on frequent inspections of progress. Also, 60% of completed traditional projects were challenged because they had gaps between expected costs and actual costs, time, and/or quality. Agile Project Management Agile Project Management (APM) is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs. APM is a lightweight model that uses informal communication style, is fewer document oriented, and uses less rules and practices. In contrast to a heavyweight methodology like the traditional life cycle Waterfall model that describes the various phases in a cascading serial fashion, APM is now becoming a common product development practice that involves building a product with the least amount of features needed (between 1-5) to get feedback for future development. The Agile method easily becomes your blueprint for starting the development process! Agile approaches are a response for the need to modernize project management for small-scale projects where clients have difficulty defining the requirements. The bottom line is that it revs up your software development (i.e., proto-typing) with a faster delivery time and more flexible approach. APM is a great software development approach for software development houses like Microsoft, Google, Oracle, SAP, and web-design organizations. There is no question that APM will increase software development project successes, reduce defects/failures, and increase user satisfaction. According to a recent survey from PMI, 80 % of companies use Agile at least some of the time and 40% said they use it either often or always. Most of the organizations that are using Agile are at a “still maturing” level regarding Agile practices. APM increases collaboration/ownership between the scrum master, product owner, and development team because they are working closely together on a daily basis. See the figure below for all the Agile roles. The Project Team consists of stakeholders/users that have an interest in the project and provide input. The Scrum Team consists of the product owner and the scrum master. The product owner is a subject matter expert (SME) that knows the business, and customers, and sets the product’s vision and priorities (i.e., roadmap and release plan). This prioritized wish list is called a product backlog. The scrum master is a servant leader or project facilitator who coaches (i.e., provides expertise on Agile processes) the Development Team and protects the team from organizational distractions. Also, this person facilitates consensus-building and stakeholder communications. The Development Team is a hands-on technical group (e.g., programmers, testers, designers, and data engineers) that produces the overall product by pulling a small block from the top of the wish list, a sprint backlog which is derived from the product backlog, and decides how to implement these pieces. The development team usually spends 2 – 4 weeks, a sprint, to complete its work, but meets daily to access their progress (called a 15-minute standup scrum). The real beauty of these short cycles is that the customer gets to see their product as a work-in-process. Scrum is an iterative approach that came from the football game of rugby where a team works closely together on a series of sprints leading to a release of a product or some functionality and takes responsibility for the results. When the next sprint begins, the team chooses another piece of the product backlog and begins the iterative cycle again.   Waterfall Model Versus Agile Agile can lead to higher product quality, increased productivity, customer approval, and team morale. Quality can affect risks because quality management on Agile projects basically reduces risks. Risks usually increase over time using the traditional Waterfall model, but that ratio is the complete opposite when using the Agile. Why? Because short durations or sprints (usually 2 – 4 weeks) prove the product is working. The following figure depicts this comparison and includes the return on investment (ROI). Agile can help increase revenue opportunity sooner and can help the self-funding of future development of new product features. Defining the right development process for your business will have a weighty impact on controlling the schedules, costs, and quality of a product. The Waterfall development model is generally suited for medium to large projects with well-defined requirements. The Agile (or iterative) development model is typically used to develop a product that has not been fully defined. This model is initially used to develop the known requirements. As the overall requirements become better understood and the product is further defined, the next iteration (or sprint) of the product is developed. Each iteration forms the foundation for the next. The fixed and estimated attributes between Waterfall (guess driven) and Agile (priority driven) approaches are completely the opposite as shown below. Also, the Waterfall and Agile lifecycles are shown below. Always remember – whatever development process you use, it must be examined routinely for improvement! Part 2 of this article will be published soon, in which I’ll explore the history of Microsoft Project or how MSP is adapting to Agile. We will also look at implementing the Agile methodology. Stay tuned! References : https://agilemanifesto.org/

  • 1
  • 8
  • 9