Search

Scrum at Scale for Better Organization Agility

Organizations that have gone Agile often started small; taking it one step at a time, from project to project and team to team. And this is the right way to go about an Agile transformation, as Scrum as described in the Scrum Guide is for single teams.  Often a massive enterprise-wide Agile transformation does not succeed because the organization is not adequately equipped to cope with the changes that come with the transformation. But as more and more organizations realized the benefits of going Agile there was an apparent need for a framework that would allow seamless transformation at a large scale.  Frameworks like Scaled Agile, LeSS and Scrum@Scale are some of the well-known and proven frameworks that have helped many an organization to successfully transition to agile and reap the benefits of long-term agility. In this blog, we attempt to look at Scrum@Scale and the principles and processes behind this widely adopted framework.What is Scrum@Scale and Why Do We Need It?Scrum was created out of a need for better software development processes. There was a need to provide developers with a methodology and a set of techniques that would not just make the process of software development easier but would empower the teams, the organization as well as the customers to align and work better. Scrum also addressed the issues that several legacy applications and frameworks couldn’t. And that was to make an organization more adaptable, more responsive and attuned to customer needs. The incremental and iterative nature of Scrum allowed for fast releases, quick turnaround times, less errors and more satisfied customers.  But as organizations, projects and deliveries grew, it necessitated the need for multiple teams to adopt and work with Scrum. But this is easier said than done. While Scrum works great for individual teams, scaling it to multiple teams and the entire organization is a whole other ball game.  While Scrum was being successfully adopted by single teams, allowing them to develop and release complex projects, it was observed that when more teams tried to work with Scrum and deliver the same quality and work, the effort wasn’t always successful. They were not able to respond at the same speed which in turn hampered business agility. Multiple teams were also not able to deliver the proportionate amount of work.  The need to find a solution to successfully replicate the benefits of agile to the whole organization and transform the culture at an enterprise-wide scale led to the creation of Agile scaling frameworks, like Scrum@Scale that brought in the benefits of Scrum to the entire organization.  Scrum@Scale (n): A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value—Scrum@Scale Guide History of ScrumScrum@Scale was developed by two stalwart organizations of Scrum Agile—Scrum Inc. and Scrum Alliance, under the guidance of Dr. Jeff Sutherland, one of the co-creators of Scrum and co-author of the Agile Manifesto. Its aim was to provide organizations with Scrum and Agile benefits such as: Help multiple teams work on prioritized goals Help in business agility and respond fast to changing requirements Help teams and networks to grow without hampering productivity Empower team members to be more self-organized Increase speed and productivityWhat Are the Core Concepts of Scrum@Scale?SCRUM@SCALE BUILDS ON THE SAME VALUE-DRIVEN CULTURE AS SCRUM: Openness, Courage, Focus, Respect, and Commitment—Atlassian Agile Coach Scrum@Scale, at the end of the day, is still Scrum. Any organization that wants to implement Scrum@Scale must already be agile and be aware of Scrum. Scrum@Scale is lightweight, and simple to understand though may be difficult to implement.  Scrum@Scale is based on three core concepts: Small Teams: Small teams are critical not just to Scrum but even to Scrum@Scale. Within multiple teams, each team should have between three to nine members. Scaling across the entire organization: The better individual teams function, more is the likelihood of Scrum@Scale implementation success. Applying minimum viable bureaucracy: It’s a well-known fact that bureaucracy and red tape lengthens processes. Agile organizations trying to scale cannot afford to take too much time on decisions. Minimum viable bureaucracy refers to the time taken to decide and execute. This approach helps small teams navigate through obstacles and bottlenecks.  The Scrum@Scale aims to ensure successful organizations, and this it does by defining Scrum values of: Openness Courage Focus Respect Commitment. Scrum@Scale ComponentsScrum@Scale is a lightweight framework and has components that help organizations better implement Scrum at scale. Scrum@Scale can be split into two components or cycles: The Scrum Master cycle ‘the how’: This cycle defines the ‘how’ accountability of the framework and includes: Team Level Process: The goals of the team level process are: Maximize the flow of completed and quality tested work  Attempt to increase velocity a little each sprint Operate in a way that is sustainable and enriching for the team—S@S Guide The team level process introduces the Scrum of Scrums, which is a Scrum team which is responsible for releasing a potentially releasable increment at the end of every sprint. This increment is integrated and consists of the sprint goals released by all the teams that are compromised in the Scrum of Scrums. There is also a new role called Scrum of Scrum Masters and an event called the Scaled Daily Scrum that make up the team level process.  The Scrum of Scrums Master: The SoSM helps the organization in the following ways according to the S@S Guide: Ensures that the SoS teams’ increments can be integrated each Sprint Prioritizes the backlog of impediments Is accountable for eliminating impediments Can be one of the team SMs or someone external to the teams Works closely with the Product Owners to coordinate the team’s Deployment with their Release PlansScaling the SoS: For very large organizations there may be a need to implement more than one SoS when a complex project has to be delivered. For this multiple Scrum of Scrums, called a Scrum of Scrum of Scrums (SoSoS) can be created.  The Executive Action Team: “The Scrum of Scrums enables a network design of Scrum teams which is infinitely scalable. The Scrum of Scrums for the entire agile organization is called the Executive Action Team (EAT). The EAT is the final stop for impediments that cannot be removed by the SoS’s that feed it”—Scrum@Scale Guide The Scrum Master cycle helps in continuous improvement, removal of impediments, cross team co-ordination and deployment. The Product Owner cycle ‘the what’: This cycle defines the ‘what’ accountability of the framework and includes: MetaScrum:  MetaScrum is the team created by multiple product owners working on a single product backlog. While it may seem difficult for Product Owners from multiple teams to work on a single product backlog, the priorities are aligned, thus allowing POs to co-ordinate their backlogs along a single path. Chief Product Owner:  A single person who is responsible for coordinating the generation of a single overall Product Backlog for all of the teams covered by the MetaScrum. This person is designated as the Chief Product Owner— Scrum@Scale Guide Executive MetaScrum: Once the MetaScrum is created and a network of Product Owners is established, it can be scaled without boundaries, for the entire organization. This MetaScrum for the entire organization is called Executive MetaScrum. The components of the Product Owner cycle Strategic Vision Backlog Prioritization Backlog Decomposition Release Planning The Product Owner cycle helps the organization to identify business and strategic goals, update based on customer feedback, break down complex and large projects into manageable tasks, maintain transparency with stakeholders etc.Where Do the Two Cycles Connect?Team Level processes Metrics and Transparency Product Release and Feedback Scrum@Scale RolesThe roles in Scrum@Scale are similar to the roles that exist in Scrum along with a few additional roles that align with the Team of Teams concept.   Scrum Master Product Owner Chief Product Owner: The CPO’s role is very similar to a POs role, but at scale. This role helps to drive production across multiple teams in an aligned manner. CPOs also co-ordinate priorities among the various POs who work with individual teams. CPOs help to: Set the vision for the product Create and manage a single product backlog that is derived from value derived from all the teams Adjust the backlog based on feedback  Scrum of Scrums Master: Just like the Scrum Master’s main responsibility is to remove impediments that may block the work of the teams, so is the role of the Scrum of Scrums Master to ensure that there are impediments that stop the release of a fully developed shippable increment.Scrum@Scale EventsScrum@Scale like Scrum has events that are an important part of getting it right. These include: The Sprint Sprint planning Scaled Daily Scrum Sprint Review Retrospective The only thing that is different here from Scrum is the Scaled Daily Scrum. This, like the Daily Scrum in Scrum is an everyday meeting that must be attended by a representative from each team. The whole team attending is not needed as this will lead to too many people being present, hence only one person, who is up to date with what’s happening in his/her respective teams, needs to attend. The Scaled Daily Scrum is a 15-minute meeting and gets members together to discuss on bottlenecks or problems that may hinder the teams from reaching their sprint goal, knowledge sharing and maintaining transparency and trust between all teams.How Does Scrum@Scale Fit in the Overall Organizational Design?Scrum@Scale is designed to scale productivity in the entire organization. Not just the development tea, but it should permeate across departments including HR, Legal, Finance, C-suite and others. Scrum@Scale allows for re-aligning of departments in response to market needs along with linear scaling. But in these times where distributed teams are the norm, it is a must for scaling frameworks to ensure that distributed teams are also well managed and the benefits they provide are assimilated. Scrum@Scale helps do this while also giving the organization the power to scale or contract on an as-needed basis. When done well, Scrum@Scale can ensure the smooth running of the entire organization.  Conclusion Dr Jeff Sutherland developed Scrum@Scale by basing it on the fundamental principles that make up Scrum. It has now been implemented by organizations around the world—from start-ups to Fortune 100 companies who are gaining the benefits of Scrum at an enterprise scale without compromising on cost, quality or timelines.  

Scrum at Scale for Better Organization Agility

6K
Scrum at Scale for Better Organization Agility

Organizations that have gone Agile often started small; taking it one step at a time, from project to project and team to team. And this is the right way to go about an Agile transformation, as Scrum as described in the Scrum Guide is for single teams.  

Often a massive enterprise-wide Agile transformation does not succeed because the organization is not adequately equipped to cope with the changes that come with the transformation. But as more and more organizations realized the benefits of going Agile there was an apparent need for a framework that would allow seamless transformation at a large scale.  

Frameworks like Scaled Agile, LeSS and Scrum@Scale are some of the well-known and proven frameworks that have helped many an organization to successfully transition to agile and reap the benefits of long-term agility. In this blog, we attempt to look at Scrum@Scale and the principles and processes behind this widely adopted framework.

What is Scrum@Scale and Why Do We Need It?

Scrum was created out of a need for better software development processes. There was a need to provide developers with a methodology and a set of techniques that would not just make the process of software development easier but would empower the teams, the organization as well as the customers to align and work better. Scrum also addressed the issues that several legacy applications and frameworks couldn’t. And that was to make an organization more adaptable, more responsive and attuned to customer needs. The incremental and iterative nature of Scrum allowed for fast releases, quick turnaround times, less errors and more satisfied customers.  

But as organizations, projects and deliveries grew, it necessitated the need for multiple teams to adopt and work with Scrum. But this is easier said than done. While Scrum works great for individual teams, scaling it to multiple teams and the entire organization is a whole other ball game.  

While Scrum was being successfully adopted by single teams, allowing them to develop and release complex projects, it was observed that when more teams tried to work with Scrum and deliver the same quality and work, the effort wasn’t always successful. They were not able to respond at the same speed which in turn hampered business agility. Multiple teams were also not able to deliver the proportionate amount of work.  

The need to find a solution to successfully replicate the benefits of agile to the whole organization and transform the culture at an enterprise-wide scale led to the creation of Agile scaling frameworks, like Scrum@Scale that brought in the benefits of Scrum to the entire organization.  

Scrum@Scale (n): A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value—Scrum@Scale Guide 

History of Scrum

Scrum@Scale was developed by two stalwart organizations of Scrum Agile—Scrum Inc. and Scrum Alliance, under the guidance of Dr. Jeff Sutherland, one of the co-creators of Scrum and co-author of the Agile Manifesto. Its aim was to provide organizations with Scrum and Agile benefits such as: 

  • Help multiple teams work on prioritized goals 
  • Help in business agility and respond fast to changing requirements 
  • Help teams and networks to grow without hampering productivity 
  • Empower team members to be more self-organized 
  • Increase speed and productivity

What Are the Core Concepts of Scrum@Scale?

SCRUM@SCALE BUILDS ON THE SAME VALUE-DRIVEN CULTURE AS SCRUM: Openness, Courage, Focus, Respect, and Commitment—Atlassian Agile Coach 

Scrum@Scale, at the end of the day, is still Scrum. Any organization that wants to implement Scrum@Scale must already be agile and be aware of Scrum. Scrum@Scale is lightweight, and simple to understand though may be difficult to implement.  

Scrum@Scale is based on three core concepts: 

  • Small Teams: Small teams are critical not just to Scrum but even to Scrum@Scale. Within multiple teams, each team should have between three to nine members. 
  • Scaling across the entire organization: The better individual teams function, more is the likelihood of Scrum@Scale implementation success. 
  • Applying minimum viable bureaucracy: It’s a well-known fact that bureaucracy and red tape lengthens processes. Agile organizations trying to scale cannot afford to take too much time on decisions. Minimum viable bureaucracy refers to the time taken to decide and execute. This approach helps small teams navigate through obstacles and bottlenecks.  

The Scrum@Scale aims to ensure successful organizations, and this it does by defining Scrum values of: 

  • Openness 
  • Courage 
  • Focus 
  • Respect 
  • Commitment. 

Scrum@Scale Components

The Components of the Scrum@Scale™ Framework

Scrum@Scale is a lightweight framework and has components that help organizations better implement Scrum at scale. Scrum@Scale can be split into two components or cycles: 

  • The Scrum Master cycle ‘the how’: This cycle defines the ‘how’ accountability of the framework and includes: 
    • Team Level Process: The goals of the team level process are: 
      • Maximize the flow of completed and quality tested work  
      • Attempt to increase velocity a little each sprint 
      • Operate in a way that is sustainable and enriching for the team—S@S Guide 

The team level process introduces the Scrum of Scrums, which is a Scrum team which is responsible for releasing a potentially releasable increment at the end of every sprint. This increment is integrated and consists of the sprint goals released by all the teams that are compromised in the Scrum of Scrums. There is also a new role called Scrum of Scrum Masters and an event called the Scaled Daily Scrum that make up the team level process.  

  • The Scrum of Scrums Master: The SoSM helps the organization in the following ways according to the S@S Guide: 
    • Ensures that the SoS teams’ increments can be integrated each Sprint 
    • Prioritizes the backlog of impediments 
    • Is accountable for eliminating impediments 
    • Can be one of the team SMs or someone external to the teams 
    • Works closely with the Product Owners to coordinate the team’s Deployment with their Release Plans
  • Scaling the SoS: For very large organizations there may be a need to implement more than one SoS when a complex project has to be delivered. For this multiple Scrum of Scrums, called a Scrum of Scrum of Scrums (SoSoS) can be created.  

The Executive Action Team: “The Scrum of Scrums enables a network design of Scrum teams which is infinitely scalable. The Scrum of Scrums for the entire agile organization is called the Executive Action Team (EAT). The EAT is the final stop for impediments that cannot be removed by the SoS’s that feed it”—Scrum@Scale Guide 

The Scrum Master cycle helps in continuous improvement, removal of impediments, cross team co-ordination and deployment. 

  • The Product Owner cycle ‘the what’: This cycle defines the ‘what’ accountability of the framework and includes: 
  • MetaScrum:  MetaScrum is the team created by multiple product owners working on a single product backlog. While it may seem difficult for Product Owners from multiple teams to work on a single product backlog, the priorities are aligned, thus allowing POs to co-ordinate their backlogs along a single path. 

Chief Product Owner:  A single person who is responsible for coordinating the generation of a single overall Product Backlog for all of the teams covered by the MetaScrum. This person is designated as the Chief Product Owner— Scrum@Scale Guide 

  • Executive MetaScrum: Once the MetaScrum is created and a network of Product Owners is established, it can be scaled without boundaries, for the entire organization. This MetaScrum for the entire organization is called Executive MetaScrum. 

Product Owner Cycle

The components of the Product Owner cycle 

  • Strategic Vision 
  • Backlog Prioritization 
  • Backlog Decomposition 
  • Release Planning 

The Product Owner cycle helps the organization to identify business and strategic goals, update based on customer feedback, break down complex and large projects into manageable tasks, maintain transparency with stakeholders etc.

Where Do the Two Cycles Connect?

  • Team Level processes 

  • Metrics and Transparency 

  • Product Release and Feedback 

Scrum@Scale Roles

The roles in Scrum@Scale are similar to the roles that exist in Scrum along with a few additional roles that align with the Team of Teams concept.   

  • Scrum Master 
  • Product Owner 
  • Chief Product Owner: The CPO’s role is very similar to a POs role, but at scale. This role helps to drive production across multiple teams in an aligned manner. CPOs also co-ordinate priorities among the various POs who work with individual teams. CPOs help to: 
    • Set the vision for the product 
    • Create and manage a single product backlog that is derived from value derived from all the teams 
    • Adjust the backlog based on feedback  
  • Scrum of Scrums Master: Just like the Scrum Master’s main responsibility is to remove impediments that may block the work of the teams, so is the role of the Scrum of Scrums Master to ensure that there are impediments that stop the release of a fully developed shippable increment.

Scrum@Scale Events

Scrum@Scale like Scrum has events that are an important part of getting it right. 

These include: 

  • The Sprint 
  • Sprint planning 
  • Scaled Daily Scrum 
  • Sprint Review 
  • Retrospective 

The only thing that is different here from Scrum is the Scaled Daily Scrum. This, like the Daily Scrum in Scrum is an everyday meeting that must be attended by a representative from each team. The whole team attending is not needed as this will lead to too many people being present, hence only one person, who is up to date with what’s happening in his/her respective teams, needs to attend. 

The Scaled Daily Scrum is a 15-minute meeting and gets members together to discuss on bottlenecks or problems that may hinder the teams from reaching their sprint goal, knowledge sharing and maintaining transparency and trust between all teams.

How Does Scrum@Scale Fit in the Overall Organizational Design?

Scrum@Scale is designed to scale productivity in the entire organization. Not just the development tea, but it should permeate across departments including HR, Legal, Finance, C-suite and others. Scrum@Scale allows for re-aligning of departments in response to market needs along with linear scaling. But in these times where distributed teams are the norm, it is a must for scaling frameworks to ensure that distributed teams are also well managed and the benefits they provide are assimilated. Scrum@Scale helps do this while also giving the organization the power to scale or contract on an as-needed basis. When done well, Scrum@Scale can ensure the smooth running of the entire organization.  

Conclusion 

Dr Jeff Sutherland developed Scrum@Scale by basing it on the fundamental principles that make up Scrum. It has now been implemented by organizations around the world—from start-ups to Fortune 100 companies who are gaining the benefits of Scrum at an enterprise scale without compromising on cost, quality or timelines.  

KnowledgeHut

KnowledgeHut

Author

KnowledgeHut is an outcome-focused global ed-tech company. We help organizations and professionals unlock excellence through skills development. We offer training solutions under the people and process, data science, full-stack development, cybersecurity, future technologies and digital transformation verticals.
Website : https://www.knowledgehut.com

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

What Is Crashing a Project in Project Management?

Projects come in different shapes and sizes. They may face unique challenges during various stages. A large and complex project is likely to face more problems than a small project that only involves a handful of people.  What are the problems a project may face?  A delay Lack of quality A problem with coordination Mismatch of expectations A poor plan Unforeseen circumstances External factors Change of scope While each of these problems could be discussed in detail, we are more interested in what you should do if your project faces any of these issues. What could be the impact of a project going off track? The completion date is delayed, the project costs go up, or the project gets scrapped. There are ramifications for each of these scenarios.  Depending on the type of project, the decision that you need to take may differ. If the project gets scrapped, then there is nothing to do other than to learn from it and find out how to prevent something like that from happening again. In the case of a delay or any other issue you should try to bring the project back on track. You could do this by calculating the cost the problem has caused. Some projects may involve penalties for missing the completion date.  You may need to advance the completion date of a project even if it is going on track because of an external factor. For example, a competitor is working on a similar project.  In both cases you will need to find a way to improve the speed of the project and shorten the time that is required to complete the project. This is what project crashing aims to do.What Is Project Crashing?Project crashing involves shortening the expected time taken for a project. This is primarily done by adding more resources to it. You may find diverse ways to add resources to a project depending on what is causing the delay or taking a lot of time. This needs to be done within the constraints of budget and quality, and must be approved and supported by important stakeholders. Definition of CrashingCrashing in a project is an activity that will shorten the completion time of a project within the optimum cost increase. You could allocate individuals from a different team to an activity that needs to be sped up.  Crashing can also be done for individual activities within the project. If shortening the length of that activity brings down the time needed for project completion, then the cost incurred is easier to justify. Crashing does not always involve adding resources. In some cases, it can also involve reducing the scope of a project. For example, the plan for a four-lane highway may reduce its scope to build a two-lane highway instead to reduce the time required for completion and to meet immediate needs.What Prompts Crashing in Project Management?The reason for the need to crash a project need not be about something going wrong with the project itself. Sometimes it is also an external factor that changes the estimated delivery time or brings a need for faster completion.  If there is a heavy penalty for failing to meet a project completion deadline, then the increased cost of crashing could be justified to an extent. A bonus for faster completion can also similarly be a reason for crashing a project. If there is an external change where a competitor is working on a similar project, the cost of not speeding up the project would lead to the loss of a competitive edge. In case there is an activity that delays a host of other activities, crashing that activity could bring benefits across the project. Or, if there are new people or an idle workforce available that was not previously anticipated, the project plan can be changed to use this additional workforce to bring down the time for completion. Sometimes the need for crashing might depend on another project. If there is a new project that requires the individuals working on the current project to be available, you may need to crash the current project. There cannot be an exhaustive list of reasons for the need to crash a project. There could be any number of project environmental aspects or an external factor that requires the project to be completed at a faster pace. An Example of Crashing in Project ManagementThere are projects happening all around us. Projects frequently run into problems or might need to be reprioritized or sped up due to a range of reasons. One of the prominent examples we saw in this was with developing vaccines. As the COVID pandemic was spreading around the world, several companies and countries were working on projects to develop a vaccine. A process that would normally take years was brought down to under a year by doing things differently. As the need to develop and deploy a vaccine became critical the funding needed was not an issue. Procedures involved were shortened or fast tracked to speed up the project. Fast tracking involves doing activities simultaneously and does not form a part of project crashing.Source Link:redd.itCaption: The image is an example of how fast-tracking helped in developing the vaccine faster by getting things done simultaneously. In a normal situation each phase would start only after the completion of the previous phase.Even though many of the bureaucratic processes and documentation were sped up, there were parts of the project that could not be sped up. Regardless of the money that goes into the project, the time required for testing and waiting to see effectiveness of the vaccine in the volunteers could not be sped up. This is the crash limit.  Within a year there were many projects around the world that successfully came out with a viable vaccine with more in the pipeline. This shows how project crashing can work effectively without a compromise on the quality. Best Practices When Crashing Your ProjectCrashing a project is usually done as a last resort. If crashing did not involve a significant cost, the timing for the activity in question would be optimized in the original project plan. There are quite a few things you should consider while crashing into an activity in your project. Critical  Path    A critical path is the chain of activities that span the length of a project. Reducing the timing of an activity in this critical path will bring down the total project completion time. Similarly, a delay in such an activity will cause a delay in the entire project.Source Link: acqnotes.comThe red line marks the critical path, and the activities on the critical path are the ones a project crashing should target. Crashing an activity that is not on the critical path will not impact the total time needed to complete the project. Cost and  Benefit    Most activities can be crashed to a certain extent. A comparison between the cost that is involved in crashing the activity and the benefit it provides can be used to arrive at a decision on which activities to crash. Resource  Availability    If an activity does not require a hard-to-find skillset, it would be easy to find more people to work on it and hence easy to crash. Organizations may even have an availability of skilled professionals who can be used for a specific activity for a limited time. The ready availability of such a workforce can also be factored in while considering crashing a project. Training  Needs    If an activity needs a specialized skillset, then it will be hard to crash it. Outsourcing a part of the activity or spending time training new personnel may be time-consuming and make the process more expensive. There will be countless factors affecting your project that you will be in a better position to assess. A lot of these factors may need to be taken into account while crashing a project. Once you have a plan and a budget in place it is important to get it approved by the project sponsors and key stakeholders.Project Crashing Management StagesWhen the circumstances where a project crashing becomes evident, then you would need to do a crash analysis to identify what changes need to be made, which activities should be sped up, how they could be sped up, what would be the cost and more such details.Source Link: cmswire.com  Crash Objective The first stage of the project crashing is to understand the need for it and the objective in terms of what is to be accomplished. If the scope of the project has reduced, then there may not be a need to add more resources to speed up the project. How to use the workforce or what amount of work can be outsourced etc. can be estimated at this stage. Critical Path Each project will have a critical path identified at the beginning. This chain of activities is what needs to be crashed to speed up the project. Crashing an activity outside the critical path does not help in reducing the project time.  Identify Activities Not every activity can be crashed. There may be activities which need very specific skills that are not easily transferable. Hence adding resources to that might prove to be counterproductive. The list of activities that can be crashed and are part of the critical path should be the ones in focus. Calculate Costs  Crashing involves an increase in cost. This increase in cost will be different for each process. Comparing these costs with each other will help you arrive at a reasonable cost at which some activities can be crashed to sufficiently advance the project completion date. Find Crash Limits Each activity will have a crash limit. This is the point beyond which an activity cannot be crashed. Understanding this information will give you an idea of how much the project can potentially be crashed.  Choose the Economic Option Once you have an idea of how much each activity can be crashed and the cost associated with it, it becomes easy to identify how many activities to target and to what extent they need to be crashed to meet the objective at the most reasonable cost. Get Approval from Sponsors  Once you have identified the most reasonable or most viable crashing plan, then you can convince the key stakeholders of the project and get their approval to implement it.  Why Project Crashing Matters When well-planned and executed, project crashing can achieve impressive feats. Projects routinely don’t go according to plan or change scope while they are in progress. You should be able to alter your project to meet changing conditions and evolving requirements.  With rapid technological changes and changing customer needs a medium- or long-term project that does not need to be altered would become a rarity. The capability to alter projects according to changing requirements will give the organization a definite advantage over its competitors. Larger projects involve a lot of teams and processes working and depending on each other. Changing anything in such an environment can have a cascading effect on other aspects of the project. This is what makes project crashing a key skill to have as a project manager. 
7850
What Is Crashing a Project in Project Management?

Projects come in different shapes and sizes. They ... Read More

What Is a Project Communication Plan?

Every project has groups of people—stakeholders, development teams, managers and so on —working collaboratively towards a common objective. Bigger projects usually involve more people working together, often across geographies. As teams grow bigger, the challenge of keeping everyone aligned to the project goals also grows. There is a greater chance of miscommunication or the risk of teams being out of sync on a part of the project that affects their work. Such challenges can derail a project and cause unnecessary complications that could be avoided with better communication. What can be done to prevent such mishaps from happening? Project managers over the years have identified this problem and one of the solutions that is being used to counter this problem is a Project Communication Plan.What Is a Project Communication Plan?So, what is a Project Communication Plan and how can it help? A Project Communication Plan is a document that identifies the communication needs that would arise during a project and aims to address those needs in an organized and timely manner. This is to be created along with the project plan so that the project moves forward smoothly at every stage. The plan considers all the different stakeholders and all types of communication that are needed to establish and maintain healthy channels of communication. Can a document make much difference in improving communications? The document is only the first step in identifying communication needs and planning to stay on top of those needs. The success of the plan will depend on how well it is executed. We will examine how it works in detail. Before that we need to understand what exactly are the things that can go wrong with miscommunication or lack of sufficient communication?Why Does Effective Communication Matter?Communication can create massive problems when it is not optimized. Too little communication hampers alignment where teams are not aware of what another team is working on and what they are expected to do. Too much communication can also slow down work. Long meetings that are not focused or clear about their objective can keep individuals away from their work, delaying projects. When the marketing team receives an update, do they go ahead and inform the sales team, or do they assume that the sales team got the update as well? When one team spots an issue that affects another team, do they flag it or expect the other team to be working on it? When there is a change in the plan who needs to know about it? What stakeholders, both internal and external, will need regular status updates? What can you expect to achieve with a communication plan?Importance of a Project Management Communication PlanA communication plan is about setting up a project that meets the communication requirements of a project. It sets up and coordinates:  Purpose of each piece of communication. Who are the stakeholders that need updates? What kind of meetings are needed? Who will attend meetings?  How or where will the meetings happen? How often will these meetings be held? What reports need to be sent to whom? The mediums of communication to be followed (both scheduled and unscheduled) How can the communication plan be improved? The last point deserves special mention. A communication plan evolves with the project. You can decide to change the frequency of meetings or reports depending on how the project is progressing. You could also add new meetings where you see the need or scrap ones that prove unnecessary. The plan provides details about the purpose of each communication and who the audience should be.  The communication plan is created through a step-by-step process that considers the diverse elements of communication required for the project. Let us see how this process would work if you were to make a Project Communication Plan for your upcoming project. How to Create a Project Management Communication PlanWhat are the steps you should follow to create your own Project Communication Plan? We’ve broken the process down for you!  Define Purpose Before starting with any idea of a communication plan you should understand the scope of this plan and what is to be achieved with this exercise. What are the issues that can be addressed in this plan? Who are the people that need to be included and taken on board for the plan to work? For a plan to work the expectation of it should be known to the stakeholders. That brings us to the question of who are the stakeholders? Identify stakeholders Stakeholders include everyone that is working on the project and everyone the project impacts. All stakeholders need to be a part of the communication plan, but to what degree they are involved will depend on the role they play.  A particular team like sales may only be involved in meetings that have an issue that impacts them. Accounting may be involved in discussions that have to do with budgets or revising expenses. Members of a steering committee will be involved in regular meetings to take stock of the progress. Frequency The third question that needs to be answered is to fix the frequency of communication. Frequent meetings can create a logjam where people talk about things, delay making decisions. Such projects get stuck. If there is a complicated report that takes up time the frequency of it could be reduced. You do not have to have all the answers at the start of the project. You should plan all the things that could make communications easier.  Tools and Medium What tools are to be used to make reports? How are the meetings going to be held? If it is to be done in a meeting room can the room be booked in advance? If the meeting is online, which videoconferencing platform will be used?  These are a few of the questions that could avoid problems when the project starts. Clarity on how a meeting is held or how a status report is to be sent can make the communication process smoother and ensure that all stakeholders adhere to the communication plan.  Review There is no perfect plan. No amount of foresight can ensure that a plan stays infallible at all levels. There will be unforeseen problems or changes in expectation that require the plan to be flexible. Plans can and should be improved continuously to make them more efficient.  If a meeting is found to be unnecessary, it can be scrapped. Similarly, if there are areas that require more coordination you can introduce new meetings or procedures to address the need for better communication. Communication Plan ExamplesEach project that you will handle will have challenges of their own. All projects will benefit from having a communication plan. A basic communication plan will look like this at a high level.ParticipantsAgenda / TopicMedium / PlatformFrequencyTimingOwnerReviewTeam AItem listFace to face (Conference Room A)WeeklyEvery Monday 3:00 pm (Local Time zone)Team LeaderFeedback formTeam BItem listWeb Conference (Zoom)Bi-weeklyEvery alternate Wednesday starting on 15/12/21 at 11:00 am (Local Time zone)Division HeadOnline surveyCustomersNewsletterMail ReportMonthlyLast Day of the month 5:00 pm (Local Time zone)Marketing HeadOnline surveyAll StakeholdersProgress ReportMail ReportMonthlyFifth of every Month 5:00 pm (Local Time zone)Project ManagerAn email mailbox for feedbackSteering CommitteReview MeetingFace to Face Meeting (Conference Room A)WeeklyEvery Thursday 2:00 pm (Local Time zone)Project Manager1 on 1 discussionsThere would be more detailed plans at lower levels of the project within teams and for specific purposes depending on the scale or complexity of the project. If you look at holding the summer Olympics as a project, there would be thousands of people involved. A team that is tasked with the accommodation of athletes, officials and support staff will have frequent meetings with each other on the specific issues affecting them. The availability of specific accommodation, the proximity to the venues or the routes they need to take may be topics of interest to this team.  When somebody from this team attends a high-level meeting with other members from different functions like telecasting, these issues may not be discussed or brought up unless there is a clear connection between them. A good project communication plan also takes care to streamline the flow of information according to its relevance.6 Best Practices for Using Your Communication PlanHaving a great communication plan does not ensure that it will be followed, and everyone will accept the plan in the right spirit. You need to be vigilant of gaps in communication and fix them wherever they appear. Ensuring that a communication plan stays effective cannot be guaranteed, but there are some practices that can dramatically improve your chances.  Focus only on a few important points It might be tempting to be comprehensive and cover all aspects of a project early on. This might overwhelm or confuse the participants, especially if it is a meeting. Make meetings, emails, and other communication focused and target only a few topics at a time. This way the participants or audience will know what the meeting is about and what was the outcome of it. Establish clarity and context Projects can involve individuals from different teams having distinct functions. The vocabulary used in communication should be simplified or the context should be set so that someone who does not know about the aspect of the project will still be able to make sense of what is being discussed and how it may relate to them.  Be vigilant to signs of confusion One of the biggest risks that you should watch out for in your communication plan is the possibility of the audience missing important facts. An email going into the spam folder or looking too routine to be opened may not communicate what it was supposed to do.  Similarly in large and extended meetings individuals are bound to lose their attention from time to time. Keeping meetings short and small can help make communication more effective. Look for signs of disinterest or confusion from your audience.  Take feedback and involve others If your audience is engaged in communication, they can and will give input. These inputs could be used to make the communication plan more effective and relevant to the stakeholders. If the participants of a particular meeting do not feel like there isn’t value in it then it would make sense to scrap it.   You do not have to bear the entire burden of improving communication across the projects. Individuals in different profiles and roles will have unique inputs. Understand communication needs You should keep looking out for the changing needs in communication throughout the project. Who are the stakeholders not receiving information in a timely manner? Who are the participants that are not contributing to or benefitting from a meeting? Asking such questions would make communications more relevant to the audience.  Build relationships If the participants in a project do not share a good relationship with each other, it would help to account for some time for them to get properly acquainted before getting into the project. Understanding who is responsible for what would increase clarity and improve the quality of communication.Benefits of a Good Project Communication PlanA good project communication plan that is executed in the way it is meant to be can help your project on several levels. All the different stakeholders involved in the project will work in a coordinated manner. There will be clarity for each participant on what is expected from them. Individual teams will have a better idea of dependencies in all directions. They will identify the teams that they depend on and the teams that depend on them. A good communication plan evolves as the project progresses, improving the effectiveness of communication. Stakeholders get accurate updates about how the project is progressing. You can identify and fix issues early before they cause problems. There is greater transparency and cooperation. Why a Communication Plan Is More Important Than Ever There is no need to stress the importance of communication. What needs attention is how the needs are evolving. We are changing the way we communicate. People expect information to be readily available. We are also working on more complex projects that span organizations, continents, and time zones. To keep all stakeholders informed at every stage can appear to be a challenging task. A good project communication plan makes the job of all the stakeholders easier. A thorough, and flexible plan can go a long way in helping you and your organization achieve the desired project outcomes and could be seen as a critical component in your project. 
9271
What Is a Project Communication Plan?

Every project has groups of people—stakeholders,... Read More

Project Management vs Product Management: Key Differences

With businesses getting increasingly competitive, steady and sustainable planning and management is needed to guide business strategies and set you up for success. Project management and product management are critical to this business strategy. These two vital roles are often confused, and while they might sound the same, there are some key differences between them.  In this blog, you’ll learn how project management and product management are two sides of the same coin, how they are complementary and how they differ. Which role is right for you? Find out!Defining Product Management and Project ManagementLet’s first start by defining the terms product and project. A product could refer to a physical product, like a new version of an Apple phone, or a software application, such as a CRM tool, or even a service offered to a group of customers. A project, on the other hand, is the effort involved, from start to finish, to create the product. Product management, therefore, is the function that is responsible for managing the product lifecycle—from the initial conceptualization, through the stages of its development and until it is introduced in the market, grows in acceptance and is eventually retired. There is no fixed timeline as it will be based on the success of the product in the market. A product manager makes sure that a great product is built, and that it meets the expectations of customers and the needs of the market.Project management is the function that is involved with the actual creation and execution of the product or service. It has a fixed timeline and is a one-time endeavour as it is completed when the project is closed, and the product is delivered to the customer. The lifecycle of the project goes through five stages—the initiation, planning, execution, tracking and controlling, and closure. A project manager oversees the project from start to finish, ensuring that all the goals are met.The Role of Product Manager Vs. Project ManagerLet’s now see what makes the role of a product owner different from the role of a project manager. A Product Manager owns the product from start to finish. They create and maintain the product vision, and act as the liaison between the stakeholders, users and the development team. They will understand the stakeholder requirements, translate them into design goals and coordinate with the team to see that the development is aligned with these goals. Quite often, the product manager is called the CEO of the product—probably because this role entails in-depth product knowledge as well as sound business sense. The Project Manager understands the product vision and goals that are laid out by the product manager, creates schedules and plans, and manages the execution of the tasks that are required to achieve the goals. They take care of the nitty gritty of the budget, time and quality, and ensure successful completion of the project. The project manager can be compared to the captain of the ship, steering the project in the right direction. To help make the distinction between the two roles very clear, imagine that you are a product manager. You might be able to answer questions like: What is the product brief? Who are the end users? What are the problems we are trying to address? How will the product look and feel? What does the competition look like, and how can you ensure that this product scores over the others in the market? And these are some of the questions that might land up on your plate if you’re a project manager: How much time do we have to complete the project? What is the budget? How can I manage the timelines? Is the team delivering on the promised quality? How can I optimize resource allocation? Here are some of the differences between the two roles, laid out in the form of a table: Product Manager’s RoleProject Manager’s RoleRole descriptionStrategic and requires product knowledgeTactical and requires planning skillsProduct visionOwns the visionFollows the visionProduct goalsOwns the goalsAchieves the goalsInteractionsInteracts with stakeholders and project managerInteracts with product manager and teamsDeals withThe ‘what’ and the ‘why’ of the productThe ‘how’ and the ‘when’ of the projectTimeframeWill focus on the product even after delivery, trying to maximize its marketability and improve sales.The job of the project manager ends when the product is delivered. They are not required to be a part of the marketing and launch.SkillsetMust be good at market research, strategic thinking and business-savvyMust be good at planning, budgeting, organizing and time management.Responsibilities of Product Managers Vs Project ManagersAlong with the difference in the two roles, comes the differences in the responsibilities as well. Essentially, the product manager has external responsibilities; those of dealing with stakeholders, management and end users, and understanding the technical aspects of the product. The project managers have internal responsibilities, which involve issues that have to do with functionalities, planning and execution, and they look inward toward the development team. The responsibilities of a product manager might involve (among others):  Understanding the product and doing some market research Gathering the user requirements and collating them Working on a business analysis, and identifying risks and opportunities Defining the product features that can maximize value Technical trouble-shooting Chalking out the product roadmap Managing tasks and deciding the priority Strategizing product launches to gain competitive advantage Retiring the product when it is no longer viable The responsibilities of a project manager are quite different, and could be along these lines: Planning doable timelines, based on the development team’s capabilities Identifying potential risks and mitigating them Managing any issues that arise during development Planning tasks Ironing out any conflicts or roadblocks to progress Allocating the right resources to the right tasks Daily management of task lists, materials, schedules, finances and so on Managing the project scope by balancing timelines, budgets and quality Is There Any Overlap Between Product and Project Managers?There is certainly quite a bit of overlap between the two roles of Product Manager and Project Manager. Both roles have the product in focus, and work to maximize product value, enhance customer satisfaction and deliver quality products on time and within budget. They are both required to be excellent communicators and should have great organizational skills and leadership capabilities. For both roles, experience and the right training are very important. However, product managers drive product development, while project managers drive project execution. There are certainly instances, usually in smaller companies, where one person could wear both hats. This does not always work out well, however, and there could be several issues that could arise as a result. These issues could include the following: As we have seen, product managers have more focus on the product itself, and not on the process of creating it—which comes under the purview of the project manager. If one person plays both roles, either of the two responsibilities will suffer as a result. Product managers usually take part in many external activities, such as attending trade fairs to keep an eye on the competition, interacting with stakeholders and so on. If they spend all their time in looking after the daily work, these activities will languish. Project managers might not have sufficient knowledge about the product itself and may not be able to define and prioritize the features adequately, as they will not have sufficient knowledge about the market. Whereas, for the product manager, it’s all about the product, and their primary work revolves around product strategy, product vision, product goals and maximizing product value. Product managers, when tasked with managing the project, might not have adequate expertise in balancing and juggling scope, quality, financial outlays and time schedules. When one person is weighed down with too many responsibilities, it’s a given that something will have to fall short. Quite often, and understandably so, quality is what gives way first. As projects grow increasingly complex, having a product manager focus on the strategy, while the project manager takes care of the tactical aspects will lead to more successful outcomes. Wrapping Up: Final Thoughts  As we have seen, the two roles are complementary, and both are equally important for successful outcomes. If you’re trying to decide on which role might suit you best, take a look at your skill sets, understand the responsibilities that come with each role and then make your decision! Rest assured, both roles will continue to be in demand in the foreseeable future, and either way you can’t really go wrong!  To equip yourself with industry best practices and start your career on the right foot, explore these sought-after project management certifications. 
5644
Project Management vs Product Management: Key Diff...

With businesses getting increasingly competitive, ... Read More