Agile vs. PMI PMBOK

There is an apparent conflict between the traditional PMI PMBOK principles that we have known and loved for so long and the principles behind Agile software development methodologies. I think this is a very strategic issue for all project management professionals. I've written a draft article on this topic that I am interested in submitting to PMI Network magazine and I’ve put it on my web site at the following address:

Becoming Agile - A Project Management Perspective

I’ve also posted this for discussion in a LinkedIn discussion group for project managers and it has caused some interesting discussion.  Here’s a few things I’ve learned from that discussion:

• It’s apparent that a number of Project Managers have some resistance to adopting Agile concepts and methodologies.  For a long time PM’s have been measured on accurately estimating and managing project costs and schedules.  As a result, they can be very uncomfortable with something that isn’t well controlled and predictable.  That isn’t entirely their fault – in many cases, the companies that they work for expect control and predictability and measure the PM’s on achieving those goals.
• Agile may require some tradeoffs of control and predictability  to achieve agility, but it isn’t an all-or-nothing situation – there are a lot of ways to tailor a methodology with the right balance of control and agility that is appropriate for the business environment that the company operates in and the risks and complexity of the project.
• There’s a lot of misconceptions about agile and many people do see this as an all-or-nothing tradeoff – either you have total control or none at all.  Some people see Agile as just a development methodology where a bunch of developers just get together and start writing code with no plan, process, and structure and no documentation or tools to manage the effort.  That’s an old conception of Agile that probably goes back 10 years and Agile methodologies have matured a lot over the 10 years, but many of those misconceptions still persist today.
• There doesn’t seem to be any inherent conflict between PMI and Agile; however, there is a perceived conflict because much of the PMI PMBOK is so heavily rooted in the traditional Waterfall approach.  Certainly PMI is moving in the right direction – discussing Agile in a PMI meeting 5-10 years ago probably would’ve been considered heresy, but there’s a lot of discussion about it today.

There seems to be a need to:

• Clear up some of the misconceptions associated with Agile among some PM’s and help them understand the tradeoffs between various forms of Agile and traditional methodologies
• Extend the PMI PMBOK to embrace Agile methodologies as well as traditional Waterfall approaches.
• Work with companies to help them determine how (and if) to incorporate Agile methodologies into their project management approach.  Agile is definitely not appropriate for all companies and all projects and the degree to which a company adopts agile or traditional development approaches should be a very strategic business decision

Chuck

The Role of a Project Management Office (PMO)

Many companies have implemented Project Management Offices (PMO’s) and I’ve worked with a number of companies at various stages of the implementation of a PMO to help design and implement that function.  A PMO can play a number of important roles in an organization if it is properly implemented:

1. Center of Excellence – One of the most important roles a PMO can play is to centralize the discipline of project management for the whole company.  Putting all of the project managers in one place should help build higher levels of professionalism and consistency in how project management is implemented throughout the organization.   For example,
   • A PMO should be the “repository” for developing and maintaining processes related to project management such as the definition and documentation of SDLC’s that are used in the company.  Centralizing these processes in one place provides a good foundation for on-going, continuous improvement.
   • A PMO can be a great way to share resources and build professionalism – if project management is done as a part-time job by people in the organization and it’s not their primary function, the implementation is not likely to be consistent and the results may not be predictable and dependable.
2. Risk Management – Risk management is a very important function particularly in companies where effective project management is critical and essential to business success.  By centralizing the project management operations in one place and developing the appropriate metrics to monitor progress and performance, companies should be able to develop much more effective risk management.
   As an example, I worked with a large financial services organization that devoted a significant amount of their business to outsourcing the management of pension and benefits plans for other major companies.  Successful implementation of each of these outsourcing efforts involved a large complex project and effective management of risks was absolutely critical to the business. The company relied heavily on a PMO organization to manage these efforts and I worked with the PMO organization to help them develop better controls and metrics to provide more effective risk management.
3. Cross-functional Perspective – Achieving an integrated view of how the business works from a cross functional perspective is a difficult thing to do, but it is an important characteristic of really excellent companies (See my book “From Quality to Business Excellence”).  A PMO can help companies achieve that cross-functional perspective.  A PMO may report into either the IT side of the organization or to the business side of the organization and I’ve seen it done both ways; however, wherever the PMO resides in the organization, it should have a cross-functional view to represent both the business and IT interests of the company.

   I have seen some level of conflict between business and IT in almost every company I've worked with...it's like lions and antelopes. Some level of conflict is healthy - there are natural checks and balances that are natural and need to be preserved. In many situations, the business side will naturally push for fast results at the lowest possible cost - on the other hand, the IT organization is many times more cognizant of the risks and complexity of what needs to be done to fulfill the business requirements and will naturally tend to take a more cautious approach to ensure that the project is successful. A PMO organization can help bridge that gap and help make the right compromises to satisfy both sides.

Wikipedia has a nice write-up on the functions a PMO performs.  Many companies are at different stages of maturity in implementing PMO’s and it probably doesn’t make sense to all companies, but it in many companies, it can play a very strategic role in helping to ensure the company’s success.  Making a PMO successful; however, is a non-trivial task and many companies are not at the level of maturity to do it easily.  Cross-functional perspective and the right level of senior management leadership is essential.  I have seen some companies where the level of conflict between the business and IT sides of the organization is so intense that it becomes highly dysfunctional.  In those organizations it would be very difficult to make this work without very strong leadership from the top to provide cross-functional direction and to overcome those conflicts.

Chuck

“Full Function” Project Management

I have found that many companies I work with have misconceptions of the role of Project Management.  Here are a few of the most common ones I’ve seen:

1. The primary role of a Project Manager is an administrator – someone who sits on the sidelines of a project and runs numbers through Microsoft Project or some other tool to track costs and schedules of a project.  That is a portion of what a Project Manager does, but a good Project Manager goes well beyond that in my opinion.
2. The role of a Project Manager and the role of a Business Analyst are separate roles that are mutually exclusive and a Project Manager doesn’t have to know much about Business Analysis. Over the past few years, with the inception of the IIBA, more recognition has been given to further developing the profession of business analysts, just as PMI has advanced the professionalism of Project Management.  The emergence of these two organizations has put more focus on the role of the Business Analyst which is a good thing, but it has also helped to build the misconception that these are two separate functions.
   The most difficult portion of a project is what has been called “the fuzzy front-end” – this is the portion of the project where the requirements are completely undefined.  A good Project Manager needs to be able to lead a project through this effort.  He/She may be assisted by one or more Business Analysts who do a lot of the more in-depth analysis of requirements, but a good Project Manager has to make good decisions about how to focus the business analysis and requirements definition effort on the most critical areas of risk to the project and also make decisions about when the requirements are sufficiently complete to begin execution of the project.
   The requirements definition effort needs to be well-integrated with the project SDLC and there are a variety of ways of doing that depending on the risk and complexity of the project. Sometimes the requirements will be completely defined upfront prior to beginning the project (e.g., waterfall) and sometimes the requirements will be defined as the project progresses (e.g., agile). That's another reason why these two efforts can't be disjoint and need to be well-integrated.
3. A Project Manager does not have to have a good technical background - that role can be performed by a Technical Lead.  This is a similar misconception to the role of the Business Analyst being separate (#2 above).  It is very valuable for a good Project Manager to have a solid technical background in order to lead application development projects if he/she is to gain the respect of the technical team and he/she is also going to be able to steer the overall direction of the project based on an understanding of the technical risks and issues associated with the project.  Of course, an application development project will probably include a Technical Lead who provides more in-depth analysis and knowledge of technical issues, just as there will probably be a Business Analyst who plays that role for business issues, but a good Project Manager has to provide the overall integration between those two areas. 
   I’ve seen some companies that actually create two different roles: (1) a Technical Project Manager and (2) a Business Project Manager.  That may be an indication that it’s difficult to find people with the breadth of knowledge and experience to span both of those roles; however, to me, it’s unnecessary overhead and may not achieve the level of integration that’s needed between the business and technology areas.

A good Project Manager has many other skills as well - one of my favorite references on this topic is an article in CIO magazine that was published in September of 2008 entitled "Six Attributes of Successful Project Managers". Here are the six attributes that this article identifies:

1. They possess the gift of foresight. Good project managers are able to anticipate and head off problems that can jeopardize deadlines, budgets and user acceptance.
2. They're organized. Organization seems like an obvious characteristic of a star project manager, but it manifests itself in a variety of ways, including in an ability to stay focused on the big picture and to prioritize competing responsibilities. "In most projects, there are so many things that have to get done that it's hard to stay on top of everything and in control of everything," says Kondo. "Being able to prioritize work for your team is a critical aspect of what a project manager has to do."
3. They know how to lead. Project managers have to interact with and influence a variety of stakeholders including their project teams and project sponsors. Since many project team members don't report directly to the project manager, the project manager has to find ways to motivate workers over whom they have no direct influence and who can make or break a project. Project managers also need to be able to inspire the confidence of stakeholders and sponsors in the event the budget or timeline needs to be renegotiated or additional resources are needed to complete the project.
4. They're good communicators. Successful project managers effectively use e-mail, meetings and status reports to communicate their ideas, get decisions made and resolve problems, says Kondo. They also understand that they need to discuss their project in the context of whatever is most important to their audience, she adds.
5. They're pragmatic. Sometimes project managers can be too analytical, says Kondo. "They analyze things to do death before they move ahead," she notes, which slows progress on a project. Good project managers focus on getting work done with the resources available to them.
6. They're empathetic. "Project managers rely on others to be successful," says Kondo. She adds that project managers can't effectively influence others if they don't understand what motivates their stakeholders. They need to learn stakeholders' concerns about a project, take those concerns seriously and address them.

Project Management is a very multi-functional role - it requires a fairly broad range of skills to be really good in this role and it is always a challenge to keep your skills proficient in all of these areas, but that's what I enjoy most about being a Project Manager.

Chuck

The Role of Change Management

I've seen several situations where a company or an organization has attempted to ram-rod some significant change in the way the organization operates through a brute force approach without considering the change management aspects that might be involved. An example is one of the situations I discussed in the article I just published on metrics. The IT organization wanted to put in place a much more disciplned approach to how the software development process was managed, but there was very little or no buy-in to that goal from the business side. I don't believe that this situation was recognized as a significant change management issue and the approach that was taken was to just start implementing a new and more disciplined methodology and deal with the conflict and hostility that created in the course of each project.

As I mentioned in my article on metrics, the lack of cross-functional collaboration accompanied by metics and goals to support that direction can make an effort like this at least 2-3 times more difficult and time-consuming as it should be and it becomes like swimming upstream to get anything done. Taking the time to address these broader change management issues that are impacting all the projects in the organization can have a huge impact; however it is not necessarily an easy thing to do. There are generally three critical elements required for any significant change management initiative to be successful

• "Burning Platform" - All of the key stakeholders involved in adopting the change need to feel a sufficient level of "pain" from the current situation that it is recognized as being untenable to sustain. If there is not a sufficient level of "pain" or there isn't a consistent feeling of pain, it may be very difficult to get consenus to adopt any significant change.
• "Vision for the Future" - Strong leadership is needed to come to consensus on what the vision for the future is (what is the company going to look like after the change has been implemented and why its important
• Steps in the Right DirectionIn any organization, there are always followers and leaders...sometimes the followers won't take any action until they see someone else moving in that direction and it looks like it might even be successful. It's important to have an action plan and start demonstrating momentum and success to build confidence throughout the organization that it is going in the right direction and is likely to be successful to build broad-based support.

Here's an example of a very successful change management initiative I'm very proud to have been part of. About 5 years ago shortly after my first book on business excellence was published, I was invited to be the keynote speaker for the Maine State Quality Award in Portland Maine. Shortly after that speaking engagement, the CEO of a mid-sized company in Maine asked me to help implement a major change management initiative. As a mid-sized company that had experienced significant growth, the challenge the company faced was that the informal management processes that had gotten the company to its current stage of growth were not going to take it to the next level. The original founder of the company recognized that and brought in a new CEO to help build that new foundation for future growth.

The CEO and the Director of Corporate Quality for the company provided strong leadership for this effort and were very perceptive in recognizing the importance of it and the significance of the change management involved in it.

• The "burning platform" that created the sense of short-term urgency for getting this done was Sarbanes-Oxley compliance. At that time, Sox was brand new and it was a gut-wrenching change that many companies needed to go through and needed to be done quickly. It was also a survival issue for many companies so, without question, it was a good "burning platform" to drive action
• The CEO of the company and the CFO personally led and facilitated a steering group consisting of all senior managers in the company to set the vision for where the project was going and steer the direction. The cross-functional leadership this group provided was absolutely essential to the success of the project.
• Finally, we put together a very aggressive working-level team who became the catalyst for getting the work started and establishing the forward momentum that was critical to get the project moving quickly.

This was a very successful change management effort led by a very strong and cross-functional senior management team. It illustrates the importance of taking a change management approach - if an attempt was made to "ram-rod" this approach through the company without this overall change management strategy, I don't believe it would have been successful. This effort went well beyond the goals of complying with Sarbanes-Oxley, it helped build a much stronger strategic framework for the company's future growth.

The results of this effort were summarized in a feature article I published in Quality Progress magazine after the effort was completed. Chuck

The Importance of Metrics

Having well-designed and well-aligned business metrics that support cross-functional collaboration across a business organization can be a key factor in the success of any project. I've been in several situations in my career where the organizational metrics were not well-designed to support the goals fo the project and it can make the effort incredibly difficult. It's like trying to swim upstream sometimes. Here are a couple of examples:

1. At one time I was a Quality Manager for a major Electronics Manufacturer.  I reported into the Quality Management chain of command which was separate from the operational business management line and only joined loosely at the highest levels of the organization.  We were constantly being asked by our higher-level management to do something like “Go over there and make them (the business and operational management organizations) do something to improve their quality” and there was absolutely no metrics on the business and operational management side to reinforce that direction at all. You can imagine what happens in that situation:
   • The poor guy who is given that task (e.g., me) has to go over there and beg, plead, and cajole or use whatever other method possible to attempt to get the business and operational managers to see the wisdom of doing that even though it may not be directly aligned with their primary metrics and goals.
   • The Quality Management organization may be put in the position of being the "Policeman" or "Enforcer" to try to enforce compliance with quality standards
   Imagine how that situation would change if there were consistent metrics on both sides of the organization - suppose the business and operational maangement organizations were measured on improving their own quality metrics and were held directly accountable for meeting those goals as well as other quality standards and regulatory requirements that may be appropriate. That radically changes the whole playing field:
   • Instead of the onus being on the Quality Management organization to meet these requirements, the onus is on the business and operational managers to make it an integral part of the way they do business
   • Instead of the Quality Manager being perceived as a policeman or enforcer, it is more likely that they will now be perceived as a value-added consultant to provide advice to the business/operational managers on what they need to do to meet these requirements
   • Instead of the Quality Management folks begging and pleading with the business and operational managers to do something, the business and operational managers are now pulling on the Quality Management folks to come help them figure out how they're going to meet these goals.
2. In a recent engagement, I was assigned to work as a Project Manager in a company where there was a very high-level of open conflict and hostility between the IT organization and the business side of the organization. The IT organization was attempting to put in place a higher level of process discipline about how the organization managed software development projects and the business side wanted no part of that at all.
   • At one time in the past, the business people had had direct control over the developers and the whole concept of having a separate IT organization with an appropriate level of controls and checks-and-balances over how applications were developed did not go over well with them at all. A number of people on the business side saw Project Managers and Business Analysts as just unnecessary overhead that just became an obstacle to interfere with them talking directly to the developers.
   • There was open hostility between the CIO of the company and the most senior business managers over this.  The COO that both the business and IT sides reported to helped mediate the overall conflict, but there were no real goals and metrics to really develop a good sense of cross-functional collaboration to improve the way software development was done.
   • The whole situation was like a very fragile house of cards that was only being held together by the direct influence of the COO and when the COO decided to leave the company, the whole situation went into melt-down and the conflict began to boil over out of control.
   You can imagine how difficult it is for any Project Manager to get anything done under those circumstances.

In both of these situations, the whole effort was made at least 2-3 times as difficult as it should have been to accomplish the goals. And all the extra effort that required was totally unnecessary if the right goals and metrics had been put in place to develop a more collaborative and cross-functional approach. It's like the difference between swimming upstream against the current or swimming downstream with the current.

Chuck

Agile versus “Non-Agile” Development

There is often a raging debate between the proponents of agile development methodology and other methodologies that are not viewed as “agile” – it’s almost a religious issue in some communities and sometimes people can become quite adamant that one particular development approach is the best and only way to do development.  I look at it as a carpenter might - you need a complete bag of tools to build a house and, depending on the type of house you’re trying to build, you may need different tools in your bag.

A software development life cycle model (SDLC) is a very important tool for successfully executing a software development project, and it’s important to choose the right approach for the right project.  Some of the factors that would go into choosing the right SDLC model are:

• Risk and Complexity of the Project – you would never choose a very agile approach for building the Space Shuttle software. The risk and complexity of the project is probably the biggest factor in choosing the most appropriate SDLC model for the project.
• Organizational Maturity of the Environment – agile works best in a collaborative, cross-functional environment where everyone on the team is committed to working together to make a rapid development approach successful. The team must be empowered to make decisions rapidly and must be capable of effectively discussing and coming to consensus to resolve any issues regarding the project direction from both a business perspective and a technical perspective. Many companies are not at that level of maturity.
• Logistical Factors There are a number of logistical factors that would also impact the selection of a lifecycle model:
  • Time Commitment - Everyone on the team (both business and IT) must be willing to commit the time needed to the joint meetings that may be needed on an aggressive schedule to make the agile approach work.
  • Geographic Dispersion of Resources - It is very difficult to make an agile approach work in a project that uses a combination of on-shore and off-shore resources or when there are a number of geographically distributed resources who are key stakeholders in the project.

• Availability of Tools – It is difficult to manage the risks associated with an agile development methodology without the appropriate tools (See comments below)

There are a number of misconceptions about the choice of an agile or “non-agile” methodology:

• “Agile” Means Different Things to Different People – It doesn’t necessarily mean just throwing some business and technical people in a room with a box of pizza and having them start to write code.  There are many alternatives for doing agile development and they don’t necessarily imply a completely uncontrolled approach to project management.
• "Agile" Does Not Necessarily Mean That Tools and Documentation Are Not Required – Some people assume that in an agile approach people just start writing code and no documentation or tools are necessary.  That isn’t necessarily the case – in an agile environment where requirements may be changing very rapidly and dynamically, documentation and tools take on an even more important role.  In this kind of environment, it can be difficult to keep everyone on the team on the same page without the right tools.
• The Choice of an “Agile” or a “Non-agile” Approach Isn’t a Black-and-White, Binary Decision - There are many shades of gray between a highly agile approach and a highly controlled approach like the waterfall methodology and any of those approaches should be customized and used intelligently to fit the needs of the project. Too often this is made into a binary decision and people may attempt to rigidly apply an approach "by the book" without taking the time to think about how it might be customized to better fit the project.

About 15 years ago I was the Director of Corporate Quality in a company that developed software and hardware products for the Telecommunications industry. One of my jobs was to get the whole company to agree on a software development methodology that the whole company would use and the company consisted of some very diverse groups in five international locations that had been added through acquisitions that all had their own way of doing things.

Naturally, representing the quality management perspective, my bias was towards having an appropriate level of control to ensure that the software was developed and delivered with reasonable levels of quality. On the other side of the fence, there were a number of developers who did not want any form of control whatsoever. After a lot of give-and-take, we wound up with an overall development process that everyone bought into and that development process got the company through ISO 9000 certification and TickIT certification (I'm sure it would have also easily passed SEI/CMM Level 2 as well, but we were never tested against that. The final approach we developed consisted of:

• Several Different Lifecycle Models designed for different kinds of projects
• The ability for the project team to tailor each of the lifecycle models to the needs of a project.

Naturally, this approach calls for intelligence and good judgement on the part of the project team to select the appropriate life cycle model and to make the appropriate decisions to fit that lifecycle model to the needs of the project. I learned a lot from that and that experience has made me a much better project manager today.

Chuck