Tag: Agile

Why Agile Doesn’t Work and How to Solve This

Written by Andriy Romanukha on March 16, 2021. Posted in Articles. 7 Comments on Why Agile Doesn’t Work and How to Solve This

Since the early 2000s, Agile has been gaining in popularity and becoming the go-to approach to project management in companies of all sizes and backgrounds.

Starting out in software development, it quickly found its way to other industries, and Agile in non-software projects shows to bring just as many benefits and results. It is being successfully used in departments all throughout the organization, including HR, marketing, finances, and general management.

Companies thrive in an Agile work environment and distinguish the many benefits from Agile implementation. Working in this framework, teams deliver better results faster and are capable of being self-sufficient and self-manageable, requiring less overview from the top. Having developed the mindset that sets up the foundation for the company’s transformation gives a sense of belonging and personal responsibility for the project’s successful delivery.

However, as much as it can be praised, it faces just as much criticism and for valid reasons nonetheless. Agile is not a solve-all solution to your project’s every problem. It won’t be a fit for every company and even industry. There are nuances and problems which arise when implementing the approach.

Such factors as company culture and composition, industry specifics, or management efficiency may call for different solutions, either sticking to the traditional waterfall approach or coming up with something completely new.

According to the latest “State of Agile” 2020 report, the most common challenges and problems when adopting and scaling Agile are as shown in the graph.

Let’s take a closer look at what happens when Agile doesn’t work and what can be done about it.

Why Agile practices might not work: Problems and challenges

How does Agile work? How do you go about implementing it? What toll does the company take in order to achieve the ever-desirable Business Agility?

Let’s see what are the common reasons why Agile fails in teams and how to overcome them:

Team and company culture

Introducing a new approach to project management and collaboration requires everyone to be on board. It’s especially the case if you are striving to turn your teams Agile – it’s a joint effort.

It’s not enough to follow the set of rules and principles. Being and thinking Agile may mean that your team members will have to take on new roles, step up and take responsibility for the successful delivery of the project, as much as for their part of the job. This would require more effective communication and collaboration, being aware of what is going on at all times, keeping track of dependencies.

Agile may create a positively new company culture that spreads from individuals to teams, to the entire organization. But it’s up to the people to be open to this shift in their mindset, be ready to let go of the old ways and work in Agile.

Business and industry specifics

The Agile approach has little to offer in industries which have to adhere to government regulations, such as healthcare, financial, construction, etc. In these cases, the product life cycle is linear and the end results predetermined. Requirements are not expected to change half-way into the project, so the flexibility in this approach brings little to the table.

Here the traditional waterfall model does the job just fine.

Agile is different in the way that it’s all about embracing the change, adapting and adjusting the plan as you go. If you can’t say that about your project, better stick to waterfall.

Failed Agile implementation

One of Agile’s characteristics is the team’s close cooperation with business. This encompasses daily communication and a constant feedback loop that allows the development team to have all the information needed to work on the product. To make such continuous cooperation possible, the management team has to be on board and ready to become the bridge between the client and the developers.

As this close daily cooperation depends on many teams and individuals to dedicate themselves to the project, it requires a thorough approach to implementing Agile within the organization. In this regard, an expert is invited to develop and implement an Agile roadmap that covers all the steps from assessment to education, setting up the processes, and further consulting and coaching.

If the team doesn’t take the time to properly implement Agile roadmap and consider all the aspects that come with Agile transformation, it may start facing difficulties when it comes to working on an actual project. Once the budgets are set and the client is waiting for you to deliver results within the first sprint, the team finds itself in hot water.

Inefficient planning

Planning is an essential part of Agile with many ceremonies centering around preparing for the work ahead. Program increment planning, sprint planning, story estimation – all this is to set the team up for success. A lot of this planning constitutes analyzing results of the already completed work and adjusting the plan in accordance with feedback from the client.

If the team fails to plan efficiently, they may have trouble completing the tasks with desirable results and meeting deadlines. Some of the things the team may struggle with are preparing a proper product backlog, accounting for dependencies with other departments, managing capacity.

Another important part of planning is considering business value and the time to implement. If the team leans too much in one direction and, for example, makes all the decisions too user-centric, this may lead to lack of real business value and results once the product is rolled out onto the market.

Team composition and responsibilities

When it comes to scaling, it’s important to understand the possible reasons why Agile doesn’t work for large projects and seek ways to address the issue.

One characteristic of an Agile team structure is that it should be small (3 to 9 people) which allows it to remain flexible and responsive to change, yet composed in a way that it is self-sufficient and can function as a separate unit of an organization.

Wrong Agile team structure and responsibilities may disrupt the workflow of a small team as it will constantly fall through and drag behind due to the lack of certain skills and knowledge, therefore, not being able to sustain itself fairly independently.

Team burnout, feeling of “it will never end”

Generally, “early wins” are a great motivator for the team. However, some may feel as if Agile, with its focus on continuous delivery and no harsh end-goal, makes it a constant race without a definitive finish line. If the team is not able to properly manage requirements and self-organize, this may lead to feelings of burnout and lack of satisfaction. Full commitment to the project is an essential characteristic of an Agile team. If team morale starts going astray, there is an underlying problem that needs to be looked into.

Advertisement
[widget id=”custom_html-68″]

When tools come before interactions

It’s often mentioned that Agile is more than merely a set of rules to follow in your day-to-day work.

“Don’t do Agile, be Agile”

You’ll see this statement quoted time and time again. The essence of becoming an Agile company is in adopting the Agile way of thinking on all levels of organization. This calls for inherently more effort and dedication coming from individuals composing the teams and departments, as you are trying to create an Agile environment.

It is not unusual that such an emphasis is placed on individual responsibility, communication and collaboration in teams and between departments, and so on throughout all levels of an organization.

Agile processes and ceremonies are just the facade, the gateway to what creates Business Agility. They are means to make the transition easier and more comprehensible. That being said, Agile artifacts should in no way supersede the people and relationships. At the end of the day, that is what builds up to business agility.

How to solve these problems

One should understand and recognize the circumstances of when sticking to the Agile approach is not feasible for the company.

Not everyone can be Agile. Not everyone has to be Agile.

However, there are ways to introduce positive changes to the organization setting it on its way to become truly Agile.

Invest in education

An important part of your journey should be building a culture around agility, which begins with education.

Consider investing in trainings or inviting expert coaches and consultants to help you along your way. Having an outsider help you set up the processes is good in a way that they get to see your established culture and routines with an unbiased eye.

Implement Agile on all organizational level

As mentioned above, involvement of the management team is valuable for the development team’s successful cooperation with the client.

The Agile approach may be implemented in pockets to see how well it is working out for the company and if there’s any benefit in proceeding with a drastic Agile transformation for the entirety of the company. The company starts seeing significantly more benefits once everyone gets in “the game”.

This includes leadership too as they set the standard for the whole company. Close cooperation and true dedication is what makes it work. There is no time and place to play strict hierarchies.

Stick to Agile Basics

A good idea would be to remind yourself of where it all started. The Agile Manifesto clearly defines values and principles that make a company Agile.

If you consider yourself Agile but don’t stick to the basics, instead opting for picking and choosing what you will or will not implement, you may be missing out on an essential part of the process. Try going back to the source material and remind yourself of what is the true meaning of “Agile”. Remember why you started out on this journey in the first place and reevaluate your priorities.

The four values defined in the manifesto are as follows:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Experiment and make it your own

Although it is strongly recommended to follow the Agile values and principles in your transformation journey, there is no need to be rigid about it. Know what works for your team and company in particular.

You see your business and industry from the inside, know its background and all the ins and outs. Leverage your own expert experience and insights to get the most out of your digital transformation. Use it as the foundation for your further improvement and look for ways to add up to it.

You may consider combining Agile with another framework, such as Scrum, or Kanban methodology, and create a hybrid solution that works best for your case specifically.

Summing up

So, the burning question is, does Agile actually work? Is it worth the effort?

Well, as with all things, it depends. Every instance may be different and have the people promoting Agile face with difficulties and obstacles on their Agile transformation journey. However, over the years, experts have streamlined the processes and defined the ways in which the above-mentioned issues may be diminished and the possible negative outcomes lessened or completely eradicated.

Bottom line is that Agile is not a miracle solution to all of your problems. However, with proper implementation and involvement of a solid expert base, Agile introduction may become the turning point for your business.

How is your Project Team Performing as an Agile Digital Team?

Written by Dr. Laurence Lock Lee on February 3, 2021. Posted in Articles. 4 Comments on How is your Project Team Performing as an Agile Digital Team?

2020 was a year during which project teams were involuntarily immersed in digital collaboration environments, thanks to the COVID-19 pandemic.

2021 is the 20th anniversary of the publication of the Manifesto for Agile Software Development. These two events will likely conspire to create the greatest leap in agile management practices since its conception.

Microsoft CEO Satya Nadella famously claimed; “We’ve seen two years’ worth of digital transformation in two months” as Microsoft raced to support the explosion of remote working. For project managers pre-COVID-19, regular tensions existed between the traditional top down Project Management Office (PMO) and the more organic agile project management approaches. As project team members have now largely been forced to working remotely, with the likelihood there will never again be 100% co-location; the cards are now clearly stacked in favour of agile management practices. While agile software projects have been shown to be twice as successful as traditional waterfall methods, a majority of medium to large organisations still sustain significant traditional PMOs.

The Challenge

Whether we like it or not, current circumstances now dictate a more rapid transition to agile teams and ways of working. The COVID-19 bomb has forced project teams into remote and distributed work. Many are struggling. There is no opportunity to go agile one project at a time. No opportunity to coach agile teams one team at a time. No time to coach traditional PMOs into agile PMO methods. The challenge now is whether you can turn the current disruption into a once in a generation positive change opportunity, or be left to a somewhat forlorn hope that things will quickly return to the way they were.

Digital can be your friend on this journey

The good news is that the management research community is rapidly reacting to the challenge. We are now seeing new remote/co-location workplace models being developed, which according to the Boston Consulting Group (BSG) could result in up to a 40% rise in team productivity and 40% less absenteeism, up to 15% less turnover and up to 20% reduction in real estate costs. The BSG notes the pandemic has forced managers to focus on the relationship aspects of work, with proximity no longer possible; referring to this “relationship productivity” as the undiscovered “real work”. This is completely consistent with agile principle No.1; “Individuals and interactions over processes and tools”: are your teams collaborating and behaving like an effective agile team?

Accenture recently published a report on “Decoding Organizational DNA: Trust, Data and Unlocking Value in the Digital Workplace”, which identifies the unique insights derived from analysing employee interaction patterns. They claim that when employed responsibly, organisations can reap a trust dividend worth more than a 6% increase in revenue growth. For the ‘want to be’ agile team, these within team to outside team analytics will become critical.

Relational Productivity – What is it and how can we measure and manage it?

Relational Productivity is not a new concept. Social Network Analysis (SNA), or its Enterprise version Organisational Network Analysis (ONA), has been used to measure relational productivity for decades. In the context of (Project) Teams, ONA can surface the social capital within and between teams. Heavily interconnected teams are likely more efficient in execution; one element of productivity. The other key element of productivity is creativity and innovation; something that requires diversity within the team; or at least welcomed access to such diversity.

What do we already know about relationship productivity in (project) teams?

Early in 2020 SWOOP Analytics published its first comprehensive “teaming” benchmarking report from an analysis of more than 5,300 teams using the Microsoft Teams product to collaborate. In contrast to traditional survey based benchmarking studies, SWOOP used the digital interaction patterns and ONA metrics for each team over a three month (pre-COVID-19) period, to identify what we considered “best teaming practices”. SWOOP has continued to monitor a large suite of teams during the onset of the COVID-19 pandemic.

What was principally discovered from those exploiting the digital teaming functions was a huge variety in the nature of “teaming” being conducted. SWOOP was able to classify the teaming patterns into the following Team Personas:

The self-directed personas mimic real-world agile teams. The Communities of Practice were like agile teams who had invited their management into their digital team. Single Leader and Forum personas reflect hierarchically managed groups.

Advertisement
[widget id=”custom_html-68″]

How are your agile digital project teams organised?

The research found digital teaming tool penetration within organisations was typically in excess of 80%, so it is not surprising a large maturity spectrum for digital teams was discovered.

In stage 1 of Digital Teaming Maturity we have groups that exist as part of a formal hierarchy. In an IT department facilities management groups are often structured in this way.

Stage 2 is commonly where most project teams will sit. Agile DevOps teams might also be at this stage. We found that when agile project teams established digital teams they would also include stakeholders from the formal hierarchy.

Stage 3 is what we have labelled the “Team of Teams” category, most akin to the aspirational agile cross functional team structure. These teams are characterised by the “Self-Directed” persona. High performing agile teams take direction from interactions with peer teams within a fluid team of teams structure.

Questions to consider for your rapid agile teams transformation

Agile Digital Project Teams are regularly at stage 2 maturity i.e. an identifiable collaborating team. Stage 2 teams make good use of technology to support their activities. They are, however, yet to discover how best to leverage digital teaming applications to maximise their productive output. Digital is used mostly for supporting activities, rather than facilitating the activities themselves. Here are some questions to consider when looking to move to the next level:

1. If you have formed a “digital” team to mirror your physical team, does it have more members than your physical team?

2. Do one or two members dominate the digital conversations?

3. Are some members absent from the digital conversations?

4. Does your team over-rely on one-on-one chats and calls in favour of all team discussion threads?

5. To what degree are your online meetings scheduled for ‘reporting up’ versus ‘aligning of’ team member activities?

6. To what degree does your team rely on hierarchical managers to broker inter-team conversations and sharing?

7. How many of your team members are only active in one or no digital teams?

If you find yourself answering ‘Yes’ to many of the above, you are falling short of being an effective digital agile team. Consider implementing digital agile team monitoring that all team members can participate, learn and benefit from.

Portfolio Management Trends Heading into 2021

Written by Lindsey Marymont on February 2, 2021. Posted in Articles. 4 Comments on Portfolio Management Trends Heading into 2021

As we close the books on the chaotic year that was 2020, it seems we are all taking a collective sigh of relief.

But before we try to wipe the slate clean and start anew, it is important to reflect on what happened and how we can adjust and improve. Let’s take a look at what happened within the Project Management Office (PMO) and discern how it impacted roles and businesses and reactions to those changes.

Here are the findings of a survey recently conducted by KeyedIn of more than 200 project and portfolio management professionals.

The State of the Industry

What are the biggest challenges PMO leaders faced in 2020? The survey results revealed that 37% of project practitioners agree resource management is the biggest challenge to their PMO, 30% say that prioritizing which projects should be invested in, while 21% responded visibility and reporting of the portfolio, and finally 12% reported project financial management as the biggest challenge to their PMO.

While these results are not so different from those we have seen in the past, it reinforces the notion that what the PMO is doing is helping the business – they just need to do more of it. This is evidenced by the results of the question, “What is the biggest challenge you face today with managing your portfolio of projects” –and 45% cited capacity planning, followed by resource allocation (28%), utilization (13%), skills tracking (8%) and managing contractors (5%) as top challenges. Capacity planning is a very mature practice that organizations, especially in times of uncertainty and risk, benefit greatly from the information and services of the PMO that are able to provide this level of planning.

What is the biggest challenge you face today with managing your portfolio of projects?	Resource Management
Capacity Planning	45%
Managing Contractors	5%
Resource Allocation	28%
Resource Utilization	13%
Tracking Resource Skill	8%

Another key finding that provides insight into PMOs of 2020 and beyond is how they define and measure success. This survey was a first-of-its-kind so it will be interesting to see if this data changes in the coming year, but this year the highest reported metric of success for PMOs was based on delivering on-time and on-budget (30%). This was higher than those delivering the most valuable projects (20%), achieving or exceeding stakeholder expectations (12%), achieving agreed upon “soft” benefits (12%) and driving the business forward (27%).

What was interesting about this piece of information was the disparity between responses from different levels of the organization. While 45% of executive level cited driving business forward as the metric of success and an additional 27% said delivering the most valuable projects with only 18% reporting success defined as delivering on-time and on-budget; PMO leaders were more split on responses with 27% reporting driving business forward as their metric of success, followed by delivering on-time and on-budget (25%) and delivering the most valuable projects (25%). As we look at the project manager level, most respondents (41%) report they are measured based on delivering on-time and on-budget, while few (16%) reported driving business forward as their metric of success. This tells us that many project managers likely focused on delivering projects rather than the impact they had on the overall business.

Executive

Achieving/exceeding stakeholder expectations	9%
Delivering on-time and on-budget	18%
Delivering the most valuable projects	27%
Driving business forward (e.g. revenue growth, cost cutting, etc.)	45%

PMO/Portfolio Leader

Advertisement[widget id=”custom_html-68″]

Achieving agreed-upon “soft” benefits (user feedback, improved efficiency, etc.)	10%
Achieving/exceeding stakeholder expectations	8%
Delivering on-time and on-budget	25%
Delivering the most valuable projects	25%
Driving business forward (e.g. revenue growth, cost cutting, etc.)	27%
(blank)	3%

Project Manager

Achieving agreed-upon “soft” benefits (user feedback, improved efficiency, etc.)	3%
Achieving/exceeding stakeholder expectations	19%
Delivering on-time and on-budget	41%
Delivering the most valuable projects	19%
Driving business forward (e.g. revenue growth, cost cutting, etc.)	16%
(blank)	3%

One final indicator from the survey of the “state of PMO” can be gleaned from how projects are being prioritized today. As we saw over the last year, the need to have a prioritized list of projects and workload, that can change and be reprioritized quickly, was a strong indicator of success. The agility to pivot when business needs change and contract or expand the number of projects in flight based on changing resource capacity was a high demand for PMO leaders. While in concept this sounds fairly simple, in practice it is very difficult to execute as there are a number of moving pieces and gathering this level of data is not easy, especially for those that had previously operated on a reactive or as needed basis. This level of intel takes months to gather, of course rendering it useless by the time it is ready to be acted on.

The survey also polled what the common methods of scoring are within PMOs learning that the biggest determining factor of what is most important to work on was — executive order (39% of responses) followed by a basic scoring model (27% of responses), then no official prioritization at all (19%). For 16% of organizations, a sophisticated scoring model was deployed. When cross referenced with the percentage of projects within the portfolio are failing, there are some interesting trends. For those that responded that less than 50% of their portfolio was failing, and then their prioritization method evaluated, the results show that those with better scoring models have a greater chance of having more than half of their portfolio considered successful.

Basic high, medium, low priority	89%
In no official capacity – just what needs to get done	52%
Mostly by executive order	77%
We have a sophisticated prioritization method with value-based scoring	96%

The PPM Impact

While the responses of this survey were anonymous and based on PMO leaders of the industry and not KeyedIn customers, we did want to evaluate what the impact a PPM solution might have on some of these organizations. Majority of the responses came from companies that have a formal PMO established (57%) and we were able to evaluate responses based on whether they reported having a PPM solution in place or not. Here are the few critical areas we saw PPM makes a significant impact:

Taking a look as some of the areas that the PMO can make an impact on the business at large, does having a solution can significantly move any levers? Those with a PPM solution report significantly higher levels of alignment of their projects and portfolio with strategic business objectives – 56% to 80% as noted above. The failure at the portfolio level also decreases significantly with the use of a PPM solution from 43% to 14%.

When looking at prioritization, even with the implementation of a basic model, there was a significant impact on success rates (from 51% reporting success on at least half of the portfolio to 84%), and a higher number of PMOs using scoring among the respondents that have a formal PPM solution. When evaluating how PMOs measured success, organizations that seek to drive business objectives or those delivering on benefits (as opposed to simply delivering on-time and on-budget) was more prevalent among those organizations with a PPM solution present – assuming it is easier to define those business driving metrics and capture data to support those key milestones with a system in place.

The last key area that was compared was around project failure, taking a look at not just how many projects fail (from 49% reporting less than half of the portfolio is failing with those using anything but formal PPM, up to 78% with less than half failing for those with PPM), but also the reason for project failure which reduced the projects reporting failure due to no clear objectives, no executive support, and not enough resources (common project problems that can be avoided with proper solutions in place) from 68% to 53% among those without PPM and those with it.

2021 and Beyond

As we head into a new year with new outlook and learnings, there is a lot at stake for portfolio leaders and a great opportunity as business is both relying on their services and the impact has never been greater. The full report on the survey findings can be accessed here: https://go.keyedin.com/projects/the-2021-pmo-outlook-report

How to Successfully Balance the Project Management Triangle

Written by Nandini Sharma on January 13, 2021. Posted in Articles. 1 Comment on How to Successfully Balance the Project Management Triangle

A project manager has to deal with many concerns simultaneously for project success.

The Project Management Triangle is associated with three major factors that affect the results of a project.

Three Points Of A Project Management Triangle Include:

Cost
Scope
Time

These Three Constraints Are Interrelated. Let’s See How:

Let’s say your client asks you to expand the scope of a current project you are working on. Now, when the scope will expand, the time taken to complete the project as well as the cost incurred will also change. That is why the interdependence between these three factors makes them a project management triangle.

Creating a balance among these three constraints becomes very important for a project manager in order to deliver a quality product.

If we look at the following picture, you can see that quality is placed in the middle of the triangle while time, cost and scope are placed at the ends. It indicates that quality is a factor that cannot be compromised with or negotiated with, whereas time, cost and scope are negotiable or subject to change.

Why Is it Important to Manage This Project Management Triangle in a balanced way?

The three constraints of project management software have to be kept in mind from the very beginning of a project. Taking care of these helps the project managers adapt to the changing requirements of a project without affecting cost and the time taken.

This triangle of project management finds its reference in Agile methodology.

An agile methodology is an approach to project management which is based on the basic belief that changes are bound to occur in the way of software development or project completion. Any unforeseen situation during the project lifecycle can demand changes and adapting to these changes successfully ensures project success.

While the traditional methods of project management which are not flexible and do not adopt changes can result in failed projects.

When you are prepared to manage any unforeseen changes, the final output of a product is not jeopardized.

Let us have a detailed understanding of the project management triangle and how changes in any one of its constraints can affect the entire project.

Terms related to the project management triangle:

Scope

By scope, we mean all the work that has to be completed and all the services that have to be provided in a project. The entire spectrum of tasks is involved in it.

Now, an addition in the scope i.e. the amount of work would mean an extension of time required as well as the money spent on a project. Also, an addition to the functionalities would also require more resources which you might not have thought about at the time of planning.

The hiring of more resources for this project puts the project manager in a tight spot as the expenses as well as the development process lengthens up.

Advertisement
[widget id=”custom_html-68″]

Time

Time is one of the vertices of a project management triangle and plays a major role in deciding the success and failure of projects. Generally, at the beginning of a project, clients ask the question- how much time it will take to complete the project and what would be the exact cost?

Now, answering this question can be a little difficult for a project manager. A proper estimation of all other factors (resources, the type of project, potential bottlenecks etc.) becomes important to calculate time.

Cost

Cost is of paramount importance and if gone beyond the estimation can lead to a serious failure of a project.

Generally, cost is calculated for clients using the following formula

Service hours(h) * Rate per hour($ )= cost($)

Change requests or requests to add functionality can severely affect the cost of a project.

How to Strike a Balance in the Project Management Triangle?

Source: https://appinventiv.com/blog/how-to-balance-project-management-triangle/

Here are the approaches that project managers can use to strike a balance between the constraints of a project management solution.

Use a Project Management Software

A project management solution becomes a medium to make better time estimations, better cost estimations as well as defining the scope becomes easier.

Let’s understand in some detail.

Basically, project management solutions like BrightWork, ProofHub, Asana, Wrike etc. become a central place where you can plan, collaborate, discuss and get reports on your projects. Your entire team can contribute to project progress and give useful input without even the need to call meetings every time.

How a project management tool helps in balancing the PM triangle.

It helps in planning your projects in a visual way using tools like a Gantt chart. You can keep all the project tasks against a timeline and see how much time each task will take. When all tasks are laid out in a timeline form, you can very well decide the resources required and the budget needed. Once clear on these parameters, you can communicate the same to the clients and also keep them in loop to maintain transparency.
Apart from this, you can see bottlenecks or problem areas of your project while the project is in progress. All your tasks can be placed in the form of a board and you can see your tasks moving through various stages in real-time. This helps you ensure that you are not running behind the decided timeline so that the project does not get overdue.
The readymade templates of project management software can help you plan your projects quickly without the need to start from scratch.
Collaboration becomes effortless and clarity on roles and responsibilities is maintained.
You can make changes in the schedule easily on a Gantt chart and everyone will be updated.
Managers can get clear visibility into the workload of individual team members and make appropriate decisions.

Conclusion

Effective planning, clear visibility into the processes, the ability to make adjustments on the go can act as the hallmarks of maintaining a stable relationship among different constraints of project management.

Communication is yet another important factor that lets your projects not slip out of hands. When an effortless and effective communication is maintained among team members and managers at all times, the efficiency increases manifold and projects can be completed successfully within decided time frame and budget.

Simplified Agile EVM – The Art of Managing Triple Constraint

Written by Dinesh Sharma and Jayeeta Dutta on December 29, 2020. Posted in Articles. 4 Comments on Simplified Agile EVM – The Art of Managing Triple Constraint

In the last few years, the project management community has garnered significant attention by the constant dilemma of choosing between Traditional Proven Ways and Agile Based Approaches.

On one side there is choice of extensive planning predictability and controls necessary to manage the projects. On the other side there has been an increasing push to drive innovation and adapt to changes. This constant conflict is often over simplified leading to bifurcated opinion with less guidance on how to strike the right balance between two extremes.

This paper introduces the SAEVM model that focuses on keys to de-risking the delivery capabilities of the project/organisation by adherence to some of the traditional project management fundamentals and practices and at the same time embracing the agile practices for true value creation that can change the project outcome.

Challenges

We often notice that middle to large size programs often run into trouble due to their inability to change with the dynamic and ever-changing market requirements. The need to remain relevant and to keep up with the competitive pressures is enormous. Our customers are now more informed and they demand more specific or personalized services, which means that to gain a competitive advantage the Project Management group must constantly look for innovation, latest tools and techniques, to gain newness, add value and customer benefits.

The Agile Project management community constantly faces the challenge of cost overrun and schedule delays. Many Agile practitioners will agree that there is also a suspicion that some organisations have taken major implementation decisions without understanding the heart of Agile methodologies, practices and how best to implement them within the organization. Also, the reduced need of project / program governance and documentation may lead to less clarity around the requirements and monitoring of the triple constraint.

A need to support project managers for enabling them to manage triple constraint or project management triangle effectively

In addition, there is an increased awareness and expectation from stakeholders and customers towards moving to the agile based models. Even to the extent that both customers and stakeholders do no longer accept any traditional models as a possibility, even in situations where the organisational environment or project context is not supportive to an agile culture. The effect of the same is that the contracts/commitments still are made from traditional mindset with limited or zero flexibility on Scope, Budget, Schedule, or Quality.

Although the context is slightly different in product and services organisations but there is limited difference in the challenges project managers face and hence there is a need to support project managers for enabling them to manage triple constraint or project management triangle effectively.

Facts and Figures

Some of the facts and figures below will state that an alarming number of projects that have failed at some point or the other stage of the project due to – (Source: PMI)

Change in the organization’s priorities (39%)
Change in project objectives (37%)
Inaccurate requirements gathering (35%)
Inadequate vision (29%)
Poor communication (29%)

Some other trends show us that –

IT projects, failure rate corresponds heavily to project size. An IT project with a budget over $1M is 50% more likely to fail than one with a budget below $350,000. For such large IT projects, functionality issues and schedule overruns are the top two causes of failure (at 22% and 28% respectively) – (Source: Gartner)

A PwC study of over 10,640 projects found that a tiny, tiny portion of companies – 2.5% – completed 100% of their projects successfully. The rest either failed to meet some of their original targets or missed the original budget or deadlines. These failures extract a heavy cost – failed IT projects alone cost the United States $50-$150B in lost revenue and productivity – (Source: Gallup)

Investing in proven PM processes and methodologies pays off. According to CIO, organizations that use proven PM practices waste 28x less money than their more haphazard counterparts – (Source: CIO)

The Solution

Tackling the above challenges requires shared effort from both Agile believers and the traditionalist EVM practitioners.

Our paper will explain that the best practices of both agile and traditional EVM models that can be encompassed to effectively manage the triple constraint.

The traditional project management community uses an approach to handle the triple constraint that further translates to work breakdown structure, cost breakdown structure and organization breakdown structure with the objective to give emphasis to provide the project teams with capabilities to manage, monitor and control them. The traditional EVM Implementation works well here to help the command and control style of project management.

can be the new way of working for project delivery teams that can be a solution such that “one size can fit all”

Agile teams are self-organised and the approach towards managing deliveries is very different. Agile teams play an active role in managing triple constraint by focusing on the progress with support from agile metrics and artifacts like Velocity, Burndown, Burnup charts. The traditional EVM concepts do not directly fit here.

To bring in the best of both worlds together SAEVM can be the new way of working for project delivery teams that can be a solution such that “one size can fit all”. While staying true to the spirit of Agile it can provide support to the organisations for bringing much higher success and effectiveness in handling wide variety of projects.

The Model

The SAEVM is based on the traditional EVM applied to the projects with an agile context. Although the projects can be very different and the agile maturity and application also varied, but the model can still be applicable in most scenarios.

Following are the four core components of the model –

• Cost Management using SACPI

• Schedule Management using SASPI

• Scope Management using SARPI

• Quality Management using SAQPI

SACPI and SASPI are derived from traditional EVM, SARPI is derived from Agile Metrics and SAQPI is derived from General Software Engineering Practices. These KPIs are described in detail subsequently and are the key drivers of the model itself.

Variations

The current IT world is very complex with a huge variety of projects.

Following are the project type variations based on type of agreement with customers –

1. Fixed Price Projects – There are several sub types within this, but for simplicity we would consider these as the projects with fixed cost, scope, and timelines. The customer takes a commitment up front on the project and there is no possibility of missing on any of the parameters. Although these types are not recommended for agile based projects, but it is a reality that these are still in abundance and customers are generally not comfortable to get into other contract type for a new engagement.

2. Time and Material Project Managed – These are customer engagements were project management responsibility lies with service provider and billing is based on Time and Material. Although these are better than the above type for agile projects, but here also a focus at project level is required and there is an implicit expectation to comply with the project budget and timelines and initially understood high level scope.

The model can be applied with ease and equivalent effectiveness to a wide variety of project category and types

3. Time and Material Sprint Managed – These are customer managed projects with Sprint responsibility expected from the team. Budget is fixed, Sprint Duration is fixed, and a constant velocity and sprint goal compliance is expected from the team.

4. Time and Material Pure Staffing – These are customer managed projects with resources from the service provider participating in customer agile teams.

There are many more project types including combinations and variations of the above types, but for simplicity we have tried to cover the most common types only.

The above context is based on services organisations. Although the context for product organisations might be different as it generally would involve internal funding but expectations from internal stakeholders /customers would be similar and hence same approach should work.

Categorisation

In the previous section we described the project types based on agreement with customers. In terms of applicability of the SAEVM model we would like to categorise, projects into the following broad categories –

1. Project Focused – These are projects where the expectation is to manage the project delivery at overall project level. Type 1 and 2 above fall in this category.

2. Time Bucket Focussed – These are projects where the expectation is to manage the delivery at sprint level or time bucket level. Type 3 and 4 above fall under this category.

The application of the SAEVM model is similar in the above two categories. The model can be applied with ease and equivalent effectiveness to a wide variety of project category and types.

Calculations

Base Metrics

These are the metrics that are required to be captured for all projects at the Project or Time Bucket level, all other metrics described could be derived from these metrics only.

These can be captured at a desired project tracking frequency, but we would recommend a weekly frequency.

Re-Planned Size (PSP)

The total size of the project can be measured in any size unit e.g. FPs, Use Case Points, Feature Points, High Level Story Points. In the absence of a better unit for size estimation, size can be in measured as Ideal Hours/Original Estimated Hours. In case, there is a change of scope (requested and approved by customer), the size can be revised based on new estimates, otherwise it should not change during project execution for Project/Time Bucket.

Completed Size (ASP)

The Sum of size satisfying DoD till date, the unit used should be same as the PSP. This gives a measure of work done till date upto a good level of accuracy. This should be cumulative of the entire Project/Time Bucket scope and partially completed stories/work should be avoided.

Total Duration (TST)

Total duration of the Project/Time Bucket from start date to end date. Calculated as total working Days between Start and End Date of the Project/Time Bucket. For Scrum Based projects this can be taken as the Sprint Count (no. of sprints) for the project. The time duration taken is with the assumption that the team would be working with a uniform pace. Initial preparation period/Sprint 0 or post development period should be avoided.

Completed Duration (CST)

Total duration of the Project/Time Bucket from start date to till date. Calculated as Total Working Days between Start and Date of reporting of the Project/Time Bucket. For Scrum Based projects this can be taken as the total Sprints completed Count for the project. The unit or basis for this metrics should be in line with TST.

Total Budgeted Cost (TBC)

Total cost or Efforts budgeted for the project/Time Bucket. This parameter is an indicator of the target cost for the project/Time Bucket.

Total Incurred Cost (TIC)

Total cost or Efforts consumed for the project till date for the project/Time Bucket. This parameter is an indicator of the incurred cost for the project/Time Bucket. The unit or basis for this metrics should be in line with TBC.

Scope Change (RSP)

Total scope changed within sprints/time bucket. This indicates the cumulative Size of the scope changes during sprints/time bucket. This is important for agile based projects where we do not expect scope changes within the sprint/time buckets. This is to be cumulated for Project/Time Bucket.

Delivered Defect Count (UDC)

Total Defects reported post-delivery to the customer. This would be usually taken as defects delivered to User Acceptance Testing and Production.

It is important to note that there is a complex relation between all the above factors and care should be taken to align them to similar context. E.g. we cannot take PSP and ASP at Project Level and TST and CST at a Time Bucket Level.

Derived Metrics

Planned Value (PV)

This indicates the work expected to be completed till date of reporting in % value, based on the schedule. With the assumption of uniform sprints/time buckets this can be taken as the ratio of Completed Duration to Total Duration –

PV = CST/TST

Earned Value (EV)

This Indicates the total value earned till date of reporting. We consider this as an indicator of the actual work completed till date in % value.

EV = ASP/PSP

Actual Cost (AC)

This indicates the actual cost incurred till date of reporting w.r.t. total cost budgeted, expressed in % value. This is taken as the ratio of Total Incurred Cost to Total Budgeted Cost

AC= TIC/TBC

Advertisement
[widget id=”custom_html-68″]

Key Performance Indicators

Cost Performance Index (SACPI)

SACPI reflects how well are we in control of our budget for the project. This is a leading indicator and is fairly accurate in providing insight about the potential budget compliance at project closure. SACPI, if calculated accurately can provide correct indications as early as in the first Sprint/Initial Stages on cost performance for the project. This gives the project manager adequate time and opportunity to take steps to bring the project back on track.

It is considered as the ratio of Earned Value to Actual Cost

SACPI = EV/AC

Schedule Performance Index (SASPI)

SASPI reflects how well are we in control of our schedule for the project. This is a leading indicator and is fairly accurate in providing insight about the potential time compliance at the project closure.

SASPI if calculated accurately can give indications as early as in the first Sprint/Initial Stages on the projects Schedule performance, which in turn gives adequate time and opportunity to the project manager to take adequate steps to bring the project back on track.

It is considered as the ratio of Earned Value to Planned Value

SASPI = EV/PV

Scope Performance Index (SARPI)

Defining performance on scope management is tricky for agile based projects. In traditional models scope management is directly aligned to controlling scope creep and effectively applying the change management process for the same.

In agile based projects changes are accepted as a norm and might still require to be managed, but we do not consider it as a right measurement for scope performance.

Instead what we would like to establish is that the requirements are managed effectively with right level of details and compliance to timelines for backlog refinement, so that there is no scope creep within sprint of the project.

The requirement or scope changes within a sprint might be a sign of ineffective scope management and might have energy losses and have an impact on project commitments.

In view of the above, we would like to define the scope performance index as the ratio of cumulative stable requirements in the sprints to the total scope delivered in the project.

SARPI = 1- RSP/PSP

Quality Performance Index (SAQPI)

Quality of delivery is at the centre of the project management triangle and arguably the most important parameter in the IT world.

The right measure must be around delivered quality to the customer and defects can be a good indication of the same.

This metrics is considered as the

SAQPI = 1 – [(UDC/PSP)/(Baseline Defect Density)]

Where Baseline Defect Density is the organisation defined baseline. In the absence of the same it can be defined at the project level based on historical data.

The above four KPIs can be utilised in the following manner to assess project health at any point of time in the project execution to derive inferences and take actions to keep project in control and lead towards successful closure

Case studies

Introduction

The SAEVM model has been successfully applied to projects for a period of more than a year with huge success. The model was used in all different categories of projects.

The improvement in project execution in terms of core delivery KPIs has been massive on the scale of 30% to 50% within short span of time.

Following are some example projects to share the experience of applying the model. The actual names of the project has been taken off for confidentiality reasons.

Case Study – Project 1 – Project Focused

Case Insight

This project was “Type 2 – Time and Material – Project Managed” with an expectation of Project Level commitments for Scope, Time and Budget.

This project was for one of our European clients. After a few initial discussions with the customer, it was understood that the requirements were very fluid and non-structured.

We started applying SAEVM to the project with two week sprint cycle and annual release roadmap with releases spread throughout the year.

The project started with Quality slightly below par, Scope Performance also slightly below par, other core KPIs completely offset to really low value with SACPI at 0.72 and SASPI at 0.55.

Implementation

The project can be considered in three stages of performance.

Stage I: The initial stage of the project involved a lot of struggle. The SASPI and SACPI clearly indicated the productivity of the team was low and it impacted both on cost and schedule and created a lag. We looked internally towards improving the effectiveness of the team. With continuous focus and steps both SACPI and SASPI could be brought well above healthy levels.

Stage II: At mid stage our project started showing satisfactory cost and schedule indicators yet quality parameters showed no signs of improvement. The team was augmented to support our delivery quality. As a result, the SASPI started to further incline but the SACPI declined. With continuous focus on quality and reduce rework, by the mid of this period quality returned to healthy levels and additional members could also be released from the project and the SACPI started to incline to a reasonable satisfactory level.

Stage III: This was the final stage of the project. This stage was relatively smooth as the core project performance was gradually settling down. However, the key challenge that we faced at this stage was a sudden peak in attrition of important resources. With mature functioning of our improved agile team the new member were brought to speed and by the end of the project, all essential project performance parameters reached an healthy levels with SACPI at 1.02 and SASPI at 1.0.

The above stages were very typical to this project but with the help of the SAEVM model different project situations can be handled with the insights provided by the core KPIs.

Case Study: Project 2 – Sprint/Time Bucket Focused

This project was “Type 3 – Time and Material Sprint Managed” with an expectation of Sprint Level commitments for Scope, Time and Budget.

Case Insight

This project followed two week sprint cycle and continuous periodic releases spread throughout the year.

The project was Driven by a competitive and ever-changing business landscape, the requirements coming from the customer were extremely unclear at the start.

The project started with quality maintained at healthy level with one spike at the initial stage. The scope performance remained at a healthy level with one spike. All other core KPIs completely offset with high variations on sprint on sprint basis. SACPI remained around 0.5 and SASPI around 1 with variation from 0.5 to 2.0.

The data points are on sprint level and hence the variation is understandably much higher as compared to long duration projects as the previous sample project.

Implementation

The project can be considered in three stages of performance.

Stage I: At the initial stage the project suffered, high variation in SASPI and SACPI which clearly indicated that the predictability of the sprints were low. The low average value of SACPI indicated that the productivity of the team was low and clearly team was incurring more efforts than budget to meet their time commitments.

With continuous focus and steps both SACPI and SASPI could be brought well above healthy levels by the end of this stage with moderate variation.

Stage II: At the mid stage, project showed overall improvement in SACPI and SASPI variations but started getting some spikes on SARPI and SAQPI. Upon further investigation and with certain root cause analysis of the spikes and process adjustments, it was brought back to the healthy levels for all KPIs by the end of this stage.

Stage III: This was the final stage which was relatively smooth, previous process improvements seem to have paid off. The variation reduced and the average value of core KPIs very close to desired value 1.0. Project got completed with both SACPI and SASPI closing at an average around desired 1.0 with variation much better improved, both other KPIs closed at near 1.0.

The above stages were very typical to this project but with the help of the SAEVM model different project situations can be handled with the insights provided by the core KPIs.

Inferences and Takeaways

Although the execution of the model was very different in two different categories but we could establish effectiveness and overall performance improvement in both scenarios.
The model’s effectiveness lies in the actions taken based on the measures provided, as with any other data driven models.
Since model is heavily dependent on data it would be crucial to have a good data quality and care should be taken for the same for effective implementation and positive results from the model.

Conclusion

It is undeniable that customer expectations are changing every day. To create a winning proposition for our customer is the key to earn the competitive edge. At the same time, we need to minimize the unknown unknowns. Setting up proper control mechanism and gain right visibility, we need to have the correct indicators in place for our project work; that will be essential to achieve the right customer value within the existing triple constraint of the project.

Whether a project is delivered via traditional or agile methods, only the outcome verifies whether the intended business value is achieved or not. Requirements will change rapidly as per the changing environment. In a fast altering environment, the risk is high, and projects and programs are complex.

SAEVM is a low risk of implementation and it coincides with the ethos of Agility. On the other hand it acts as a control mechanism for project deliverables. In the process it brings in excellence from both worlds of Agility and Project Management.

With the model being applied and its effectiveness established with a wide variety of projects, it can be taken further to be applied into all different contexts with ease and in the process derive success on projects helping the business.

About the Authors

Dinesh Sharma

Over 22 years of experience in IT Industry with more than 15 years in Project management and more than 7 years into handling agile based deliveries. Extensive Project, Program and Delivery Management Experience comprising of end-to-end execution of complex high risk projects.
Excellent track record with different type of projects – Development, Testing, Support, Transition, IT Setup; all with 100% success rate.
Demonstrated Exceptional Team Management and Leadership capabilities – handled large teams, managed an excellent team motivation and a low attrition rate, applied leading through Innovation and Leadership by example.
Multicultural Customer handling experience – worked for customers and customer locations across Europe and US. Not limited by any Technology or Business domain – Managed Projects in varied technologies and business domains with equal ease, maintained hands-on experience in core technical skill areas.
Conducted training and seminar organisation wide, written articles/whitepapers and delivered talks on global platforms and conferences on different topics related to Domain, Technology and Process.

linkedIn: https://www.linkedin.com/in/hidineshsharma

Jayeeta Dutta

A Project Management Professional, with extensive experience in Project Management, Business Analytics and Program Governance in IT Consulting. HealthCare domain, Finance Global Markets, Insurance in Techno-functional domain.

Strong business acumen, ensuring strategies and projects are aligned to the business objectives that yield high ROI and impact.

A total of 12+ years of professional experience with 9+ years in Project Management carries a strong understanding of Project Management methodologies, Program Integration, Resource management

Program governance and PMO Practices across industries.

Successfully carried out several techno-functional projects from end to end in Finance systems, Program Integration, system migrations, Business transitions that involved Solution designing, Resource Management, Planning and Implementation etc.

Strong acumen in reporting and governance skills and have developed strong business relations with business partners and teams located in various geographical locations. A green belt certified Project manager with several successful implementation of Quality projects.

linkedIn: https://www.linkedin.com/in/jayeeta-dutta-9108281a/