3 Critical Similarities Between Project Management and Agile
By Harold Kerzner, Ph.D. | Senior Executive Director for Project Management, IIL
The intent of this blog is not to enter into the debate of whether or not Agile and Scrum are outgrowths of project management, but to show some of the similarities that between them that have increased their rate of success. There are three similarities that I will discuss.
Executive Understanding
Years ago, executives viewed techniques like project management as something that was nice to have rather than a necessity. As such, project management was seen as a fad that could disappear quickly. This resulted in limited support for any and all techniques like project management, except in a few project-driven industries where project management was a necessity.
The growth of project management, as well as Agile and Scrum, is largely due to a better understand of these techniques in the top floor of the building and the accompanying support. Consider the following words used by executives in describing project management:[1]
- An international, multicultural and global approach
- Allows us to capture best practices
- A technique for continuous improvement
- Selling customers on our project delivery process is just as important as selling them the deliverables
- The processes increase our credibility as a trusted partner
- Allows us to have repeatable success and accelerate the time to value for our customers
- The processes provide us with a competitive advantage
- The processes shorten our time-to-market
- The processes allow us to create a more integrated and agile organization
- The new processes allow us to eliminate unnecessary steps that we used before
- We can now provide our customers with end-to-end multiservice solutions
- We are now making decisions based upon facts and evidence rather than just guesses
These comments could very well reflect how executives see Agile and Scrum today rather than just project management. For many of the companies that speak these words, managing traditional, Agile or Scrum projects is more than just a typical career path. In these companies, once every few years, there is an assessment as to which four or five career paths are a necessity for the company’s growth over the next decade. In these companies, project management, Agile, and Scrum mastery are now seen as some of the four or five strategic competencies necessary for the firm to grow. The support for these processes now exists at the senior-most levels of management.
Trust
Within the last decade, significantly more companies have begun trusting project leaders to make both project and business-related decisions. For decades, many of the business-related decisions were made by the executives, project sponsors or business owners. Simply stated, there was an inherent fear that project leaders would begin making decisions that were reserved for the executive levels of management. Decision-making controls were put in place.
Today, we believe that we are managing our business by projects. Everything we do in the company can be regarded as some sort of project. As such, project leaders, whether in traditional project management, Agile or Scrum, are seen now as managing part of a business rather than merely projects, and are expected to make both project and business decisions, within certain limits of course.
Methodologies
When mistrust prevails, executives maintain control by developing rigid methodologies for managing projects. The methodologies are based upon rigid policies and procedures, and every project manager on every project must follow the same policies and procedures described within the methodology. While project leaders may be allowed to make “some” decisions, all critical decisions are made by the project sponsors or the executive levels of management.
Today, rigid methodologies are broken down into four components; forms, guidelines, templates and checklists. As a project leader, picture yourself walking through a cafeteria. On the shelves are all the forms, guidelines, templates and checklists that make up the methodology. Because of the trust placed in you, you have the right to select only those forms, guidelines, templates and checklists that you need for your project. This is a freedom that did not exist years ago.
Agile and Scrum activities, as well as many forms of traditional project management, use the term “framework” rather than methodology. Frameworks are flexible and allow the project leader and the team to select which of several tools will be used on a given project. There may be as many as 50 tools from which selections can be made.
In my opinion, the biggest reason why Agile and Scrum have been successful is because of the trust that senior management has placed in the hands of the project leaders, or Scrum Masters as they are called in Scrum. Accompanying this trust is the freedom to use only those portions of the framework that are appropriate to satisfy a particular client’s needs.
These three similarities are greatly enhancing our success rate on traditional, Agile and Scrum projects. Are there other similarities? Most certainly there are. But in the author’s opinion, these appear to be the most critical today.
[1] Adapted from Harold Kerzner, Project Management Best Practices: Achieving Global Excellence, IIL, and Wiley Co-publishers, 3rd edition, 2013; Pages 13-15
Harold Kerzner, Ph.D. is IIL’s Senior Executive Director for Project Management. He is a globally recognized expert on project management and strategic planning, and the author of many best-selling textbooks, most recently Project Management 2.0.
Why Your Agile Implementation Failed
Join IIL’s virtual conference on Thursday, May 4th for more insights on Agile, Scrum, and Kanban.
By Roy Schilling
At one point in my career, I was a manager in a large financial organization. Being tired of missed deadlines and disappointed customers, I wanted a better way to deliver – faster, better, cheaper. I had been reading about Agile and how it had helped organizations with exactly what I was looking to solve.
My Agile journey started pretty much like everyone else – hours on the internet and a 2-day class. At the end of the class, I was the proud owner of a certificate and had a high-level of confidence that I could implement this Agile thing in my organization. I quickly looked for a project, formed my team and started executing – now we’re Agile! The result, however, was something quite different from what I expected. The team never really formed, we had personalities that didn’t work well together, people were getting yanked out of the team for “special assignments”, and a whole host of other anti-patterns which caused us to ultimately fail – and in a big way.
The reality was that I had no idea what I was doing. I had no experience and no one to help set up the guardrails needed to keep the team (and me) headed in the right direction. Sadly, this is a very common situation. Lots of energy, desire, motivation, but no experience to make it work. Training was a great start, but not enough to guarantee success.
I could have walked away with my failure, and declared Agile to be the problem. “It just can’t work in my organization” is something I’ve heard far too often as an excuse for simple mistakes. Instead, I was fortunate enough to have met someone with significant experience in the industry, who offered his help to mentor and coach me. After spending a short time together, we got my team re-aligned, analyzed skill sets and personalities, setup team working agreements and started working with leadership to help them understand their part in all this. In short, he got me back on track.
One of the most important things he helped me with was in becoming a better leader. He helped me understand that I was spending too much time managing down, worrying about “resource allocation” and dealing with the minutia of daily activities. I had hired good people; it was time to get out of their way, let them do their jobs and give them the support they needed to accomplish the goals they set out to achieve. This was a major change from my management style, and one of the most difficult and important lessons I had ever learned as a manager. Without his help, I may never have made that leap.
To summarize, hiring a coach taught me:
- To be an active listener
- To give my team the environment and support they need and trust them to get the job done
- To effectively communicate with everyone, and always find the time for face-to-face discussions (and daily stand-ups)
But most importantly,
He taught me how to successfully implement Agile and get everyone on the same page; how to destroy the barriers and bring a new mentality to the company as a whole.
Having a coach to help me through the transformation (personal and organizational) was critical to the success of my organization. Without his involvement, I would likely have had failure after failure, or just walked away from it altogether. The cost to my organization would have been significant due to those failures, and I still would have had disappointed customers.
I’ve since moved on and have become an Agile coach myself, but even with many years’ experience behind me, I still reach out to other coaches and my mentor for advice, and to share my experiences to help others as well.
If you are transforming your organization, or just yourself, take advice from someone who has already gone through it.
Avoid my mistakes – find a coach/mentor, learn from others who have more experience than you, ask for help and embrace your mistakes.
Roy Schilling is an Agile Trainer and Coach and is based in the Charlotte area. Roy has 30+ years in IT and 16+ years practicing Lean/Agile in small to large organizations. Roy’s certifications include CSM, CSPO, CSP, ACP and ICP-ACC.
How to Understand Soft Skill Metrics in the Next Generation of Project Management
Many years ago (i.e., before the Internet existed), I worked with a well-known colleague who was quite proficient at writing books. When I asked him where all of his ideas came from, he pointed to a small pad of paper and a pen in his shirt pocket. He stated that whenever any of his students asks a good question, he writes down the question immediately and later creates text material for his books around that question. Therefore, these questions often lead to individual brainstorming sessions for the creation of intellectual property.
I received a question from Sajjad Falahati, who is in the EMBA (Executive MBA) Program at the Alborz Institute of Higher Education in Qazvin, Iran:
I am an Iranian student currently working on my MA dissertation in which I am trying to customize and predict future phases of a flour mill construction project in Sarakhs SEZ, northeast of Iran.
The biggest question I have in mind is how to predict and translate behavioral nature of the Kerzner Project Management Maturity Model quantitatively.
Also, the project not being initiated yet challenges my work in that it leaves no chance for me to put my customized model into practice for now (and I believe the reason lies in the futuristic sort of approach that the Kerzner Project Management Maturity Model naturally takes).
I would be very grateful to hear your comments on this.
This is an excellent question and the timing could not have been better since I am in the early stages of preparing the next edition of my text on the Project Management Maturity Model (PMMM).
Maturity in project management is most frequently measured in terms of paperwork generated and hard skills related to the creation of forms, guidelines, templates and checklists. With hard skills (especially in regard to deliverables created with paperwork such as components of a methodology), there are several metrics and measurement techniques that can be used to show progress toward various levels of maturity. But in regard to soft skills or the behavioral side of project management, not many metrics existed in the past. However, today they are receiving some attention. There are some attempts to establish these behavioral metrics, but they are still in the infancy stages of development.
Some of these behavioral metrics under consideration include:
• Collaboration
• Commitment
• Culture
• Emotional maturity
• Employee morale
• Leadership effectiveness
• Motivation
• Quality of life
• Stress level
• Teamwork
Identifying these metrics is easy. However, the obstacle is the measurement technique—finding ways to perform the measurements over time will be challenging. Measurement techniques are now coming of age.
In the next version of the PMMM, I will be adding in material related to:
• The maturity process for establishing metrics and KPIs
• The maturity of project sponsorship and governance for levels of the PMMM
• Establishing criteria for measuring project business value along the PMMM path
• Transformational project management leadership
Mr. Falahati’s question is directly related to the last bullet above and indirectly related to the other three bullets. There have been numerous books written on the behavioral side of project management, specifically on effective project management leadership. Most of them seem to favor situational leadership where the leadership style that the project manager selects is based upon the size and nature of the project, the importance of the deliverables, the skill level of the project team members, the project manager’s previous experience working with these team members, and the risks associated with the project.
Historically, project managers perceived themselves as being paid to produce deliverables rather than managing people. Team leadership was important to some degree, as long as what was expected in the way of employee performance and behavior was consistent with the desires of the functional manager who conducted the employee’s performance review. In the past, project managers were expected to provide leadership in a manner that gave the employees a chance to improve their performance and skills, and allowed the employee to grow while working on project teams.
Today, project managers are being asked to function as managers of organizational change on selected projects. Organizational change requires that people change. This mandates that project managers possess a set of skills that may be different than what was appropriate for managing projects. This approach is now being called Transformational Project Management (TPM) Leadership.
There are specific situations where transformational leadership must be used and employees must be removed from their previous comfort zones. As an example, not all projects come to an end once the deliverables are created. Consider a multinational company that establishes an IT project to create a new high security, company-wide email system. Once the software is developed, the project is ready to “go live”.
Historically, the person acting as the project manager to develop the software moves on to another project at “go live,” and the responsibility for implementation goes to the functional managers or someone else. Today, companies are asking the project manager to remain on board the project and act as the change agent for full, corporate-wide implementation of the changeover to the new system. In these situations, the project manager must adopt a transformational leadership style.
Transformational project management is heavily focused upon the people side of the change and is a method for managing the resistance to change, whether the change is in processes, technology, acquisitions, targets or organizational restructuring. People need to understand the need for the change and buy into it. Imposing change upon people is an invitation for prolonged resistance, especially if people see their job threatened. Transformational projects can remove people from their comfort zones.
TPM, as it relates to the PMMM, is shown in the exhibit below.
Although there are many elements of human behavior to be considered in a project management environment, I generally focus upon the factors that can influence project management leadership. In a simple context, leadership in project management is based upon one or more of the following:
• Leadership during the execution of a project where the project manager has no direct control or influence over the assigned project personnel
• Leadership during the execution of a project where the project manager has direct control or influence over all or some of the assigned project personnel
• Leadership during the “go live” stage of a project where the project manager may have direct control or influence over the workers for an extended period of time
Mr. Falahati’s question about the behavioral nature of the PMMM has forced me think about the necessity to include more behavioral information in the PMMM. Obviously, this is now becoming more important than I had anticipated. The growth of metric measurement techniques, especially for soft skill data, is now making this possible and I will certainly take this under consideration.
In February of this year, Wiley released a new book I wrote titled PM 2.0: Leveraging Tools, Distributed Collaboration, and Metrics for Project Success. I am conducting research for the next edition of this book, titled PM 3.0. One of the critical topics for PM 3.0 will be a better understanding of human behavior on projects and establishing behavioral metrics.
More research needs to be done on measurement techniques for use of soft skills metrics. Should Mr. Falahati continue on with his education and pursue a Ph.D., I would recommend this as his dissertation topic, and I eagerly wait to read his Ph.D. thesis.