The Gartner group recently issued a whitepaper entitled the 7 deadly sins for a PMO. The first deadly sin identified was Failure to be Agile and deliver value.
As IT leaders, we are well aware that a large majority of organizations do not have a fully designed Agile plan. It is important to understand that most organizations historically have been waterfall organizations. Most SDLC structures work from the top down and are limited in their use of Agile. They have yet to deliver on a Dynamic Development Life Cycle (DDLC) for their PMO organizations. There are a number of reasons but they boil down to the following
- Agile is a new discipline, and has not yet been adopted by the organization in its SDLC.
- Complex legacy based applications do not lend themselves to an Agile model.
- The team has not been adequately trained and not prepared for Agile techniques.
- Best practices have yet to have been developed by the organization.
Agile is a new discipline, and has not yet been adopted by the organization in its SDLC
Most organizations have just been toying with the idea of Agile as a discipline. The SDLC (Systems Development Life Cycle) in most organizations have not been redesigned to include an Agile or Dynamic methodology. During a recent project for one of my clients, I had redesigned the SDLC to incorporate an Agile structure. While the company was not in a position at the time to bring Agile in as its primary development method, there need to be ways to incorporate it in areas that would provide the greatest impact.
The Gartner report identifies the following:
Achieving these traits, however, involves deep, fundamental changes for a PMO. It means tossing out old, familiar tools, forms, processes, habits, and attitudes — many of the very things that made the PMO successful in the past.
The PMO needs to take a front seat in redesigning the way the enterprise works with all tools including Agile. A step by step approach needs to be developed not only to incorporate Agile but to bridge a gap to the new technology. The PMO’s role in bridging the gap needs to be designed and fortified before going further.
Complex legacy based applications do not lend themselves to an Agile model
Legacy applications especially those written in COBOL or CICS do not traditionally lend themselves to an Agile model. Understanding that premise, it needs to be taken a step further. Is the purpose of redesigning the application, or performing program maintenance? This is where the difference lies. If we are taking the thousands of lines of code, and making a small change (adding some new functionality to an existing code), without changing the application functionality or what it does, Agile will not be the method of choice for completing this effort. There is too much code to evaluate, and it would take more time to bring a team together than it would to make the change and implement it. In addition, most COBOL, and CICS programmers are not necessarily versed in using SPRINTS to complete their projects.
Agile would work effectively, in both the requirements gathering phase as well as the testing phases of the project. It is here, that SPRINTS could be developed to gather the requirements and see if any of the proposed additions could have effects further on down the line. While during the testing phase, recommendations can occur during the SPRINTS and return it back to the development team to implement it. The question is would this new methodology save a company significantly enough to execute the change.
There is no doubt, that if an organization was looking to redesign data input screens, create new functionality, or implement web-based queries, Agile would be the recommended methodology. The organization needs to decide if Agile can resolve their issues, or if it will be just another tool in the shed. However, despite all of this, there needs to be guidelines and training to deliver the result.
The team has not been adequately trained and is not prepared for Agile techniques
It is one thing to want to move to Agile, it is quite another to assume that the team is ready to move. Many of the legacy organizations considering the move to Agile are saddled with teams that do not have the in-house discipline in the Agile methodology. Running SPRINTS, adding SCRUM Masters, gathering requirements in a new way, as well as ensuring the end user involvement requires training and commitment from the entire organization.
The role of the PMO now moves from Project management to more of a Product management role. Things will move quickly, and projects would require a different type of management process. Methodologies that organizations have been accustomed to will require re-work. End users and subject matter experts will need to be included more, and there will be a level of involvement from all levels that can no longer remain at arm’s length.
It is imperative that the organization be aware of the required discipline, and that it is informed and committed to the additional workload. While savings can be identified in terms of development speed, what many organizations do not take into account is the amount of time that will be required of the end users and subject matter experts. In the Waterfall process, the end user time is usually limited to the business requirements gathering and testing phases of the project. During the Agile process, they would be required to be present during the SPRINTS and would need to take a more active role.
Best practices have yet to have been developed by the organization
It is here that the PMO processes need to be redesigned, and effective measures developed to manage the process. While the PMI process that most project managers have been trained upon outlines specific documentation and tasks that need to be undertaken by the project management teams, some of this work is no longer effective under Agile. Project managers are now more facilitators in the process and need to adopt new methods to the process. They need to keep the teams focused and moving, and in effect create more dynamic methods for implementation.
A few years ago, a major banking organization decided to move totally to the Agile process. This was done without a pilot, or without ensuring that the team was comfortable with the new strategy. Projects were failing, requirements were incomplete, projects began to fall behind and were not completed on time. The biggest reason was that the organization did not develop or invest in developing best practices that would have ensured the adoption of the methodology. Many of the existing long-term developers left the organization, and it took a longer time than they anticipated to shake out the kinks. It was not because Agile was an inappropriate platform for development. It was because a plan to move to Agile was never developed.
This specific organization never created the best practice to adopt. End users and subject matter experts were not used to the level of commitment that was required of them, so they did not routinely show up for Sprints. It was too late before the organization’s PMO realized that they had made some major errors. The ideal way would have been to take a number of the projects that needed to be developed in Agile, and pilot the program. In this way, they could have developed best practices that could be used as a foundation for future growth. In addition, they needed to determine the types of projects that were more suited to Agile, and create a foundation for success. That foundation would be used to ensure the success of the implementation as well as the adoption of the new methodology.
Agile is a tool, and like any tool, it cannot be used for everything. A clear roadmap for developing an Agile environment needs to be developed and then cultivated and followed. Teams need to be effectively trained, and a clear methodology to implement that change needs to be identified. Sometimes as with all new ideas, we get stuck in the novelty of the idea and lost in the execution. Since everyone is doing it, there must be a reason to that. We sometimes get so excited that we forget that the goal is to do things more effectively, not to conform to what everyone else is doing. Also note, that no organization is going to broadcast that they have failed to deliver. They will always paint a picture of success. However, dig deeper…
A PMO organization needs to effectively deliver. They need to develop am an advisory role. Choosing a new tool and saying that the tool will solve all of the ills of an organization is naïve at best. There need to be sound reasons for implementing a tool, and Agile is just one of the tools. Just as the fact that not every project will follow each project methodology the same way, it will be difficult to ensure that every Agile project will be the same. There will be projects that are reconciled to the fact that Waterfall or some hybrid of both Waterfall and Agile needs to be used to ensure that the project is successful.
It is important, however, that we do not get too caught up in the methodology used and not on delivering successful projects. What good is delivering a product nobody wants. Regardless of the methodology, the ultimate goal is to deliver projects that are effective for the organization. A successful PMO needs to ensure that not only are projects delivered on time and on budget; but that they have been implemented successfully, and the end user has adopted the new application. Success is measured not only on delivering a project but also on ensuring that it was effective at solving a particular problem. Building a bridge is an effective use of resources, ONLY if the bridge was needed. If not, building a bridge to nowhere would be considered a waste of resources as well as a waste of precious capital. As the PMO, it is important that we understand our role is not only to ensure that projects are completed effectively but to ensure that the projects meet the goals of the organization. As stewards of the organization, the PMO needs to ensure that this is our primary function.
About The Author:
Frank D’Onofrio, PMPDynamic, polished and professional senior technology consulting leader with over 20 years of experience leading all aspects of IT. SA proven leader in developing Program Management Office (PMO) and Data Governance programs for Fortune 100 organizations.