Skip to main content

Author: Kiron Bondale

How Do You Sell Agile to Your Control Partners?

When selling the value of agile transformation, the focus is often on the benefits to the sponsoring business or to delivery team members.

But in most organizations, there are multiple internal stakeholders beyond these who will help or hinder your progress towards becoming agile. Control partners such as Finance or Risk might be skeptical or downright resistant to fundamental changes to delivery approaches.

So how do you sell agile to these stakeholders – what’s in it for them?


Finance departments want to ensure that the company’s funding resources are being utilized effectively and that good accounting principles such as writing off sunk costs are being practiced. They also want to know that project investment decisions are delivering expected business results. Hence, they are likely to be somewhat leery of approaches which eschew traditional safety blankets such as detailed requirements baselines or multilevel Gantt charts.

Agile delivery focuses on early realization of business value but also early, objective indication of critical issues which can trigger timely project termination decisions. Agile also supports changing the traditional project funding model from full scope commitment to a value-driven tranche approach which can reduce non-value add gold plating or the use of excess project budgets to fund unnecessary PCRs.

Human Resources

HR departments have significant effort invested in tools such as job families and programs such as performance management or individual recognition. The transition of delivery staff from specialists to generalizing specialists as well as the need to recognize teams as much as individuals might concern HR professionals from both a work effort and a attrition risk perspective.

While there is little doubt that there will need to be effort spent in changing the current state, effective agile delivery can result in higher levels of employee engagement and job satisfaction which in turn can reduce common challenges for HR teams such as low employee morale or unplanned time away from work.

The agile journey can also generate other more subtle benefits such as a broader pipeline for leadership talent which results from delivery staff taking on greater ownership for team development and self-organization, as well as better business continuity and succession planning through the cross-training and broader learning that are natural outcomes of becoming generalizing specialists.


Risk partner concerns with agile delivery relate to the potential impacts of poorly designed or implemented changes as well as the potential change storms which can result if the frequency of changes exceeds stakeholders’ ability to adopt changes.

While these are valid concerns, they assume an undisciplined approach is taken to agile delivery.

Disciplined agile advocates early and regular engagement of key enterprise stakeholders to ensure that a fulsome set of requirements is incorporated into solution design. While continuous deployment might be practiced within non-production domains to reduce implementation windows, this does not imply that the same high frequency must be applied for implementing production changes.

Agile reduces delivery risk by requiring teams to sufficiently explore key areas of technical and operational concern early in the project lifecycle. On traditional projects, such risks rarely get effectively addressed till late in execution phases by which point the organization has expended significant funding and the common response is to throw good money after bad.

Agile also reduces the magnitude of changes through an increased frequency of delivery. Yes, the first implemented change might be significant, but subsequent releases will incrementally evolve capabilities making it easier for operational teams to absorb the changes.

Finally, with a greater emphasis on quality throughout the lifecycle, there is a reduced likelihood of hidden defects which are a common source of operational or reputational risks.


Procurement groups will be concerned that earlier engagement of vendors might increase delivery risk due to a lack of a fully detailed requirements baseline. They might also worry that changes to funding approaches will reduce their ability to negotiate cost effective deals with vendors who were used to trading pricing reductions for long-term contracts.

Procurement approaches will need to evolve by moving away from traditional full lifecycle fixed cost contracts to incentive-oriented contracts which encourage vendors to deliver the highest value and highest risk items early and frequently. This can in turn result in a healthier relationship with less procurement headaches as vendors will be less inclined to low ball bids and then use costly project change requests to make their profit.

Agile also increases transparency of vendor delivery through frequent demos, business value milestone-based payments and backlog visibility which will make it easier for procurement teams to administer active contracts.

As with any change, it is crucial to start with answering why it is beneficial to not just the organization as a whole but to individual impacted stakeholders who are needed to support the agile transformation journey.

Project Management Lessons From Greek Mythology

For those of you who have attained a CAPM, PMP or other project management credential, you likely learned about the Delphi method while studying for the exam.

Delphi provides teams with an approach to leveraging the knowledge of a group of stakeholders to make a decision while minimizing impacts from bias or personality. The etymology of the term is the Oracle of Delphi who was a legendary soothsayer in the ancient world that lived in Greece. She was consulted by visitors on a variety of topics. In project management, Delphi method can be used to develop estimates which are a prediction of future performance.

Related Article: The Change Control Myth

But this isn’t the only link we can draw between project management and Greek mythology!


Cerberus was a large, multi-headed dog who guarded the gates of Hades (the underworld) and was responsible for preventing the dead from escaping. Heracles (often called Hercules) is famous for having captured this hound as one of his twelve labors. In the myth, Heracles was challenged to capture Cerberus without using weapons – he did so by wrestling the hound and squeezing its head until it submitted.

Think about the last long, arduous project you were on. Didn’t it feel like you were in hell? Cerberus could remind you of the multiple gatekeepers you need to wrangle before your team can be released from the project.


While on the topic of multi-headed creatures, let’s not forget about the Hydra. Even though it bears the same name as one of the Marvel Universe’s evil organizations, the Lernaean Hydra was a monster with the remarkable regenerative property of being able to regrow one of its heads after being chopped off. Heracles managed to slay this beast by cutting off each head and cauterizing the neck stumps before they could regenerate.

Ever been on one of those projects where it felt like issues were proliferating like cockroaches in a dirty restaurant? For every issue your team resolves another two emerge. This can happen if we are resolving the symptoms (the heads) instead of focusing on identifying and resolving the root causes.

Cleaning the Augean stables

Yet another of Heracles labors was to clean the stables of Augeas. A huge number of immortal cattle were housed in the stables which meant they had never been cleaned. Rather than use his remarkable strength to clean out the filth, Heracles diverted two rivers and let nature do the hard work.

Sometimes we are faced with a project task or issue which looks like it will require a ridiculous amount of effort to accomplish. Rather than rushing headlong into the fray, savvy teams will step back and come up with a more thoughtful approach.

The Lotus-eaters

While attempting to return home to Ithaca, Odysseus and his men encountered the land of the Lotus-eaters who were extremely lethargic and apathetic due to frequent consumption of lotus fruits and flowers. Three of Odysseus’s men ate lotus products and became lethargic and unwilling to resume their journey home. Odysseus was forced to resort to tying up these affected men and forcibly bringing them back on board his ship.

On long projects, the team can sometimes lose sight of the expected business outcomes. They can get distracted with completing documents or other by-products of the delivery process or be so focused on the triple constraint that they miss changes in the underlying rationale or requirements for the project. A smart project manager will recognize this situation so that they can redirect their team’s efforts in a timely manner.

The Minotaur

You probably know that the Minotaur was a half man, half bull monster but what you might not remember is that it lived in a challenging maze knows as the Labyrinth. When Theseus went to slay the Minotaur, he brought a ball of thread with him. To avoid the risk of getting lost in the Labyrinth, as he entered the maze, he tied one end of the ball of thread to the door.

Risk management is frequently given lip service by project teams, but this can cause them to lose their way. It might not take a lot of effort to tackle key risks early in the life of the project, but the longer the team waits to do so, the greater the probability or impacts of realization.

The Flight of Icarus

Icarus is famous for his failed attempt to escape Crete using wings which his father, Daedalus, had made from wax and feathers. His father warned him not to fly too high or too close to the sun but he ignored this warning and fell into the sea after the sun melted the wax.

Stretch objectives provide an opportunity to be creative and challenge themselves, but the team has to understand their constraints and limitations to avoid a spectacular failure.

Mythology does more than provide literary entertainment; it also provides practical lessons to improve project performance!

“Myth is much more important and true than history. History is just journalism and you know how reliable that is.” ― Joseph Campbell

Just Because You Can Doesn’t Mean You Should

Continuous delivery is the ability of an organization to deliver new or modified capabilities to customers as soon as those changes have been constructed and fully tested.

Such practices exist in many technology-as-a-core-competency companies such as Amazon where changes get deployed to production every twelve seconds.

Related Article: The Importance of Continuous Project Tracking

This capability sounds very attractive, doesn’t it?

Imagine all the challenges which could be eliminated if your organization evolved from infrequent releases:

  • Missed market opportunities resulting from pre-emptive launches from competitors
  • Reduced return on investment for delayed capabilities which are no longer considered innovative
  • Encouraging stakeholder complacency as they grow unused to change and a higher likelihood of change resistance when changes are eventually released
  • Wasted administrative effort spent in planning and managing large release deployments
  • Reduced employee engagement or satisfaction resulting from the lack of reinforcement which occurs when stakeholders are quickly and actively using the deliverables produced by the team

Few would consider this to be an easy transformation as it goes beyond introducing some new practices or tools to requiring significant structural and behavior changes across the organization.

Here are just a few of the challenges your company will face if your leadership chooses to accept this mission:

  • Moving from project-focused, short-lived teams to capability or value-stream aligned, long-lived teams. No one denies the performing power of a group of professionals who have worked together for many months or even years but for organizations which have enjoyed the productivity illusion of multitasking team members across multiple simultaneous projects, having to “cut their coat according to their cloth” is a bitter pill to swallow.
  • A shift from individual to team-based performance evaluations and recognition. Formal recognition and annual performance evaluation programs usually focus on the individual, and this can encourage team members to act in their own interests instead of the best interests of the team. The shift to continuous delivery forces a company to move from encouraging specialized silo skill sets to generalizing specialists who play well in whole teams.
  • Technology limitations such as lower or higher environments which can’t be provisioned quickly or have to be shared with other teams, lack of tooling to support continuous delivery or application footprints which don’t lend themselves to incremental updates. Continuous delivery works very well for applications which were designed for cloud environments, but legacy applications tend to have well-established release schedules which can be very difficult to modify.
  • Internal or external governance requirements which prolong transition efforts. These could include the need for independent verification and validation after internal quality control efforts have completed or formal reviews with audit or regulatory bodies.
  • Operational teams which are ill-equipped to accept frequent change. Applications might need to be instrumented to be self-maintaining, and delivery teams would ideally ensure that production support collateral is released in line with functionality. This is a big leap for organizations which are used to having extended warranty periods after releases to give operational teams a chance to play catch up.
  • Changes to traditional budgeting approaches. While the temporary nature of projects can provide finance teams with a sense of security about funding decisions, continuous delivery requires leadership teams to allocate available funding to capabilities or value streams. This shift is still capable of aligning with fiscal annual budgeting cycles but will change the engagement model from one of project submission to value stream justification.

These blockers are par for the course when it comes to scaling agile within traditional organizations but let’s say you could wave a magic wand and resolve of them.

Continuous delivery will still not make sense for all of your organization’s capabilities as stakeholder context and expectations will influence timing on how quickly a given change should be made.

Think about the mobile applications you’ve downloaded and installed on your smartphone or tablet. By acknowledging their end user agreements, you’ve authorized the companies which developed them to update them whenever they feel like. This is a normal expectation for these platforms.

But think about the home pages for critical websites such as those of your bank, insurance or healthcare providers. If those were updated every few hours, imagine how challenging it would be to have to relearn how to complete the simplest activities. Even if the changes were aimed at improving usability, very few users have the appetite or capacity to absorb frequent changes without negative impacts.

One merely has to look at the inadvertent Darwin awards won and other unintended consequences of Google Glass, auto-driving cars or Pokemon GO to recognize that the pace of technology evolution far exceeds our ability to appropriately absorb it.

Effective change management eats continuous delivery for breakfast and just because you can deliver frequently doesn’t mean you should!

Project Management is a lot Like Baking

I love to bake.

Nothing puts a smile on my face faster than the smell of a fresh batch of goodies or the instant, positive feedback I receive from family and friends when they sample the outcomes.

So let’s discover what project management lessons might be learned by stepping into the kitchen.

Related Article: Project Management is All About Trust

Quality in, quality out

You can clearly taste the difference when you bake with higher quality ingredients. Yes, you could bake a cake with cheaper inputs but isn’t the effort you are putting into the exercise worth the greater investment? Arguably, the extra amount spent will provide a taste which far exceeds the incremental costs.

The same holds true when staffing our projects. We shouldn’t settle for lower performers just because they have the capacity. As I’ve written previously, we need our team members to bring capacity, commitment, AND capability – all three attributes are required for project success.

You need to be strategic about resourcing. It sounds great to get a team of all Grade A performers, but a short-lived team of “all stars” is likely to be too costly, unavailable, or would generate more headaches due to ego clashes than the incremental value they would provide.

As with baking, you should identify the one or two key ingredients which will result in a substantial uplift and focus your efforts on securing those.

When baking a chocolate cake, I don’t worry about getting the best quality flour, eggs or butter. But I will favour Dutch cocoa over regular, and real vanilla extract over the cheaper artificial variety. The result of using those is evident with every bite!

Context counts

One size does not fit all when baking. The cake which turns out great when our oven is set at 400 degrees for 50 minutes might still be uncooked when we try the recipe at a friend’s place. Doubling the size of a recipe doesn’t mean you can get away with doubling the baking time – you might end up with charcoal. And finally, the quantities you use of specific ingredients might not scale linearly.

The same holds true with project management.

The complexity of a project does not scale linearly. The reason that Fibonacci sequences are well suited for relative size estimation as the effort involved to complete a work item at higher levels of uncertainty could be exponentially greater than for simple work items.

Practices also need to be tailored to the specific context of a project, the culture of the team, and the delivery maturity of the organization and stakeholder ecosystem. Applying rigorous practices which worked well on a large, complex project to a much smaller initiative is a needless waste and trying to manage a large project with the practices which worked well at lower levels of complexity is professional negligence.

Companies should embrace frameworks, not methodologies. When implemented well, the former provide sufficient guidance to ensure that the right process tailoring decisions get made whereas deploying the more prescriptive latter can often result in the Goldilocks tale of either too big or too small for most of the projects in the portfolio.

Follow recipes until you are safely able to experiment

When I bake something for the first time, I will follow the instructions exactly in terms of ingredients and process steps. But over time, as I get more familiar with it, I can safely begin to experiment by trying different ingredients or approaches. I know that I can get away with reducing the quantity of sugar in my cake recipes or substituting a different liquor when making Amaretto cookies, but that confidence comes with experience.

When we first start to manage projects, it should be the same way. With the support of a seasoned project manager and sufficient process guidance, we should be able to manage a small, low complexity project successfully. On our second project, we will replicate those behaviors and practices which helped us on the first project. Over time, our competency with multiple hard and soft tools will improve so that we can pick the right approach for the specific context of a situation.

But this competency will only come through progressive increases in project size or complexity. Taking a project manager who has been successful managing small maintenance projects and handing them a highly complicated system replacement program would be as foolhardy as asking an amateur baker like me to bake a multi-layer wedding cake under time and cost constraints.

As Tom Douglas put it “If you don’t have the confidence in baking, commit to making the recipe three times. The first two, do it exactly the way I’ve told you to make it. Twice. The first time you’ll screw it up. The second time it will come out pretty good, and then the third time, make your adjustments.”

When we bake, we hope that the outcome will be tastier than just the sum of the ingredients – in that, it is exactly like managing projects.

Which of These Leadership Traits Do You Demonstrate?

A March 2016 HBR article shared the results of the first round of a research study conducted by Dr. Sunnie Giles, which focused on identifying a short list of key leadership competencies. The study involved the participation of 195 leaders from 30 organizations in 15 countries.

The article provides examples of how these competencies can be demonstrated by executives or functional managers. Project managers are equally responsible for exhibiting these behaviors so here are some ideas on how each of the top ten traits can be applied within the project management context.

Has high ethical and moral standards

As a project manager, you have the responsibility to act with integrity and fairness in your dealings. Your behavior sets the standard by which your team members will operate. If you are a member or credential holder with PMI, this privilege comes with the requirement to follow the PMI Code of Ethics. Beyond the impacts your actions have on your project stakeholders, if you compromise these standards you are also damaging the credibility and reputation of the project management profession.

Related Article: Collaborative Leadership: Managing in the Matrix

Need to elevate your leadership skills?  Check out these Leadership courses.  New, from Project Times!

Provides goals and objectives with loose guidelines and direction

You must ensure that your team members have a clear understanding of what a project’s expected outcomes are and why the organization is investing in it. However, this shouldn’t be mistaken as permission to micro-manage the team’s work. While you do need to monitor and control performance, the emphasis should be on encouraging your team to come up with the most efficient and effective means of achieving the project’s objectives while removing hurdles from their path.

Clearly communicates expectations

In functional or weak matrix organizations, you might have limited or no formal input into the performance evaluation of team members. In spite of this, if you don’t effectively set expectations with them as part of their onboarding to your team, you shouldn’t be surprised when issues arise. Once again, I am not giving you carte blanche to dictate every step of how their work should be performed. You should make it clear what your needs are as far as reporting and control and then help the team to develop as a set of practices which will fit their working style while still meeting your requirements.

Has the flexibility to change opinions

You have to make a number of decisions over the course of any project, but one of the attributes of a good project manager is the ability to help team members and other stakeholders lift their heads out of the sand if they are affected by tunnel vision. Increased stress levels cause people to narrow their focus so this is where mindfulness techniques can help you get some perspective and redirect the energy of the team.

Is committed to my ongoing training

Successful project management is not just about reaching a destination – the journey is equally important. If you don’t take the time to learn what the development objectives are of your team members, you aren’t fully answering the WIIFM question for why they should commit their efforts to your project.

Even if the scope of the project is virtually identical to multiple projects they’ve contributed to in the past, you can still provide them with stretch opportunities to help their further development. And when it comes time for them to leave the project, act as a champion for their development objectives with their people managers.

Communicates often and openly

More than 90% of your time will be spent communicating, and ineffective communications have frequently been identified as a contributor to project failure – enough said!

Is open to new ideas and approaches

As project managers, we are on the pointy end of change, but it’s amazing how often we are unwilling to consider an alternate approach to an issue or decision. One of the quickest ways to stifle the creativity of your team will be to take the “my way or the highway” approach – it won’t take too long for them to realize that their ideas aren’t really being considered.

Strive for an eclectic set of skills and backgrounds when negotiating for team members – the greater the diversity, the greater the likelihood of unique solutions.

Creates a feeling of succeeding and failing together as a team

Although your team members come from different departments that doesn’t mean they won’t be looking for the opportunity to connect and form bonds with peers from other areas of the organization. Helping to create those connections and focusing on team building efforts throughout the project’s lifetime will increase the likelihood that your team members will act in the best interests of the team and the organization as a whole.

Helps me grow into a next-generation leader

Every interaction with our team members provides the opportunity to coach them and encourage the development of their own leadership skills. My own interest in the profession was sparked by a project manager who “walked the talk” that the role is more than just tools and techniques. How you conduct yourself in challenging situations will make a lasting impression on your team.

Provides safety for trial and error

If your project microcosm reflects the fear of failure culture of your organization, creativity and efficiency suffer as team members stick to tried-and-true approaches and frequently employ wasteful CYA techniques to shield themselves from the consequence of failure. You are in the best position to create a working environment where your team members can afford to fail fast, learn from their failures and succeed.

Developing leadership competencies such as these will not only raise your profile within your company but will provide a good standard of behavior for the stakeholders whom you work with.

As with quality, elevating organizational capability is everyone’s responsibility.