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:

• User Need (Text10) – priority can be low, medium, or high
• Story Points (Text11) – the number of product requirements for each feature (each product requirement should have a simple description stating what it should accomplish)
• State (Text12) – status (i.e., done, in progress, or not started) of the sprint or feature
• Sprint (Text13) – the sequence in which you work your sprint roadmap to build your product which could include your backlog (see Figure 1.5)

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.