Fernando Santiago

Fernando Santiago

Wednesday, 30 May 2018 11:50

Synchronized Strategy Execution

synchronized-strategy-execution-thumb

Synchronized Strategy Execution

March 27, 2016

 

Success in executing business strategy remains elusive.  Norton and Kaplan claim that nine out of ten companies fail to execute strategy. This is similar to the success rate, or should we say failure, of new ventures. However, here we are talking about organizations that have invested significant amounts of time from their higher-up echelons, paid small fortunes to consulting firms to come up with strategy documents that, at best, get translated for the lay person and disseminated throughout the organization. Office employees, shop floor workers and even managers receive this information by sitting in a meeting where the CEO talks on a screen about the strategy and how, this time, rest assured, it will happen. They may even receive a cue card or some kind of material to reinforce the spiel. After the meeting, most often than not, they return to their jobs and continue doing exactly the same thing they were doing before, exactly the same way. At the end very little happens and, the following year, the cycle repeats.

A solid strategy, a real one, exudes direction for execution.  It clearly defines what needs to be different to achieve organizational objectives, and how each department will contribute, what will be done differently and what will be done no more (always so hard…).  When executives produce this level of strategy, middle managers have something solid to work on, as they just have to acquire or deliver the capabilities that will allow the business to achieve their targets in business objectives, which in turn will be reflected in financial indicators (growth, increased profits, etc.).  This should be the norm, but it is the exception. But this is formulation, the relatively good link of the chain. God protects us.

In the majority of organizations that have a strategy formulation process, a step of translation is needed, mainly because formulation is poor. This is usually the responsibility of internal consultants or planning departments, who link financial projections to targets for KPI’s (key performance indicators) and identify the projects and/or operational activities that will generate the expected targets. And here is where this nice (really?) story breaks apart. Very few companies have the talent or the tools to run simulations that generate targets for KPI’s that could be sufficient to achieve financial projections. As an example, the organization estimates that in order to increase revenue by 5% annually, they need to increase the average number of line items per order. The current value of the KPI is 3.2, and this needs to increase. The question is by how much, and when.  Targets for KPI’s should be synchronized with targets for financial indicators. In most companies this exercise is just a guess. Modeling, when available, usually gives the final target for each operational result required to achieve the desired financial performance in the “to-be” or desired scenario. However, intermediate targets for KPI’s are no more than a guess. Someone may catch the idea that until we deliver some projects we cannot expect change, so the first year is usually flat or minimal change, but after that, it will just climb to wherever it needs to get, likely using a linear scale, which is almost never right.  In most cases there is no simulation, so even the final targets for the KPI’s are nothing but a guess.

The second part of the question formulated above, the “when” refers to how the KPIs will progress from their current measurement to the desired target.  Expected change in a KPI, besides external factors, is related to the completion of projects and operational initiatives identified as a result of planning; at least this is the way it should be done. Projects will likely deliver capabilities that will enable the business to do things they couldn’t do before, or do things differently. It is through the use of new capabilities that the KPI’s will get impacted, together with operational initiatives that are not necessarily projects (i.e. rationalization of distributors, adjust credit rules, etc.). Both projects and operational initiatives have one thing in common: they take time and have an end date, and it is only after the end day and usually with some lag, that effects can be measurable in the KPI.

Besides timing, each project or operational initiative will have a relative contribution. As an example:

  1. Project A has a contribution of 30%, Project B of 50% and Operational Initiative C, 20%.
  2. The delta between the current value of the KPI (3.2) and target value (5) is 1.8
  3. This delta is then prorated to the projects and initiatives, based on their relative contributions
  4. Considering expected delivery and lag to see results after delivery, the contribution in each year from each project or initiative can be calculated
  5. Adding the yearly increments from each contributor, the targets for the KPI can be calculated

synchronized-strategy-execution

Fig 1.

In this example:

  • There is only a minor improvement in the indicator or KPI in year x +1  (0.18)
  • In year x +2 the increment is more than three times the previous year increment (0.675)
  • In year x +3 the increment takes the KPI to the target, the increment starts to level, and is only 50% higher than the previous year (0.945)

This example clearly drives the point that targets for KPIs cannot be arbitrary and certainly not linear. However, this is just the plan, and projects get delayed and/or re-scheduled, and changes impact the ability of the business to achieve targets, creating a perception of failure that is not real, just the consequence of business decisions.  This is what, intuitively, has driven a wedge between operations and project delivery, as projects do not get to production quick enough to generate the expected business results.

From the financial perspective, investments in projects do not generate the expected impact on growth, revenue or cost reduction, creating yet another perception of failure that is perfectly explainable considering actual project delivery.

At this point in the discussion, the need to link project delivery to operational results (KPIs) and financial results should be evident. Current approaches to implement strategy execution, like Kaplan and Norton’s Balanced Scorecard, cover the concept of contributions, but do not reflect the “kronos” aspect, the timing of all these pieces, which are not random balls in the air, but synchronized gears in a machine with a logic that very few people in the organization understand. This clearly explains the frustration and lack of results in strategy execution, benefit realization management, portfolio management and all other approaches that try to manage these pieces as independent silos.

Synchronized Strategy Execution is, in essence simple: there is no “secret sauce”, no more logic than the one presented in Figure 1.  However, capturing the cause-effect relationships for a Strategic Business Unit between initiatives, capabilities, operational results and financial results, plus the relative contributions among all these elements, can appear like a daunting task. This simple but laborious mathematical problem can, and has been resolved with relatively simple modeling tools, and it is not an obstacle to the implementation of this approach.

When cause and effects relationships between projects and operational results have been defined and can be managed, benefits from projects are simply reflected, through relative contributions, on operational results. At this level, management of benefits does not represent an additional layer of work, as it is significantly simplified due to:

  • Reduction in the problem of double counting benefits from multiple projects, added to the impact of projects from previous portfolio years. It is frequent that the same benefits are claimed by different projects, year after year, and seldom realized or verified.
  • Estimation of benefits through contribution to financial results is relatively easy to calculate and easy to verify. Tracking operational results is part of the day to day operation, so no extra work is required, so it gets done.

Finally, the concept of consistency in results is the “icing on the cake” in this approach. Consistency in the results from the three “realms”: project delivery, operational results and financial results; provides valuable insight into the viability of the strategy. Common scenarios are:

  • Sunny day: projects are delivering as planned and operational results are meeting expected targets, while financial results also meet the expected targets. Life is good.
  • Cloudy day: project delivery is behind, and so are operational results. As a consequence, financial results are not getting the expected targets either. Not nice, but it makes sense. Corrective action is needed in portfolio management, maybe architecture, as well as in project delivery.
  • Confusing and expensive: projects are delivering as planned, but operational results are not reaching targets. This can mean two things:
  1. The model is missing something: operational results are impacted by other factors not considered in the analysis, which explain the variance between expected and actual measures.
  2. Projects are delivering on time, on budget and to requirements, but fitness for use (the second component of quality) is not there. In other words, the business is not getting the expected results from the capabilities delivered, achieving no impact on operational results.
  • Confusing and embarrassing: Projects are delivering as planned, operational results are being achieved as expected, but financial results are not there. This scenario could mean two things:
  1. External factors not considered in the cause-effect analysis, explain the financial results (i.e. changes in the environment, assumptions that did not materialize, etc.).
  2. The strategy is flawed and the plan, even when execution is successful, is not capable of achieving the expected financial results. This is probably the most difficult scenario to manage, particularly when it comes to communicating this to the “executive row”.

Synchronized Strategy Execution is a simple solution to three very complex problems: strategy execution, project selection/portfolio management and benefits realization management. As with any approach related to strategy, this cannot guarantee success, but it will get all the pieces done in a smart and effective way, providing executives with the information they need to manage strategy execution.

 

Fernando Santiago MBA PMP CSM

Managing Partner at P3M Solutions, a Canadian company that provides consulting, training and software applications in the area of strategy execution through portfolio and benefits management.

Sunday, 30 October 2016 14:28

Agile and the Gates of Hell

Agile and the Gates of Hell

How the Stage-Gate process has evolved to enable governance for Agile projects

By: Fernando Santiago

In the beginning there was chaos. On the first day God initiated the project, on the second day defined requirements, then design and you know how the story ends. On the seventh day God looked at the beautiful waterfall He had created, and saw it was good. But paradise did not last long, and as technology started to accelerate and markets could not wait years to get technology solutions, Adam the developer decided to eat of the tree of wisdom, and Agile was born. Initially, it was perceived by the higher powers as “cowboy development” and they were expelled from the garden and confined to start-ups. But Agile managed to thrive and made its way back into paradise, only to find that the higher powers expect it to pass, like any other mortal, through the Gates of Hell.

When Dr. Robert Cooper, a Canadian professor at Mc Master University, came up with the Stage-Gate process thirty years ago, his focus was, and still is, innovation and product development, particularly in manufacturing. However, structured organizations like financial services, telecommunications,  etc.;  with significant IT portfolios saw the potential and adopted some form of a Stage-Gate process as the core of their portfolio governance. Today, around 80% of large organizations in North America use the Stage-Gate process. The success of this approach to govern IT project approvals was based on the perfect fit with the waterfall process which, at the time, was the only mode of delivery that existed, besides “cowboy development” that is still healthy and kicking.

As Agile has become mainstream in the past few years, structured organizations that use a Stage-Gate process are finding that, as initially defined, does not handle Agile very well. Once an idea is approved in Gate 1 (see Figure 1 below) and it is decided that delivery will follow an agile/iterative mode, things start to complicate. Stage 1 is not too “hellish” for agile projects, as it requires high level requirements and design, which are also found in the early stages of agile. It is in Stage 2 where things start to complicate, as the business case, in most structured organizations, should be based on a defined scope, well understood and defined requirements and design, and a detailed plan for execution. Agile projects simply do not have any of these: scope is flexible and they only have high level requirements and design, and a release plan with no detail on what will go in each iteration, not to mention tasks within each iteration.  

Figure 1: Stage-Gate Product Innovation Process

 

Furthermore, the business case for Gate 3 requires an estimate of time and cost: a baseline which, in waterfall projects comes after months of planning. Here is where agile projects really break the rules in most organizations. In order to get to a point where an agile project can make a commitment of how many more iterations are needed to get to an initial release, the full team needs to be assigned, and this team starts executing actual work, development and testing, so they can assess their velocity and use it to develop the release plan. In projects where a vendor participates in the development of the solution, they also need to be involved and, of course, get paid. At this stage, “development” has not been approved yet, so the gates in paradise start to shake badly and turn into the gates of hell every time an agile project gets assessed.

The good news is that the Stage-Gate process has evolved to include agile projects. In recent years Dr. Cooper has modified the process to include spirals, a series of build-test-feedback-revise loops, as depicted in Figure 2. This Agile-Stage-Gate leverages the agile framework using prototypes or actual product to get customer feedback and evolve the solution in an iterative fashion.

 

Figure 2: Agile-Stage-Gate

 

Structured organizations are now adopting this new version of the Stage-Gate process, as a response to the need to speed, to shorten time to market. Agile does not necessarily mean faster, but it does deliver sooner, as viable product can be put into production in a few months, rather than a few years.

However, in order to restore paradise, it is not only Finance and IT Governance that need to evolve. Other functions like Procurement, Legal, Organizational Change Management, etc.; also need to adjust their processes; if they don’t they could become a roadblock for agile projects which, in most cases, are used to implement innovation that supports business strategy.

One of the statements in the “Agile Manifesto” (a document put together by the “gurus” of agile in 2002) is “collaboration more than contract negotiation”. Procurement and Legal departments in many structured organizations are simply not prepared to make these changes to their processes and, most important, their beliefs. I remember when I started negotiating the development of BRMTool, the Benefits Realization application for my company, P3M Solutions: the negotiations with the off-shore development company where stalling as our legal advisor was trying to use the same approach that worked for waterfall projects in this project that was, not only agile, but was going to venture into the use of an off-shore vendor, Peru Software Factory (PSWF), and use agile, a combination that was not frequent and even considered not-doable at that time. At the end, the president of PSWF and myself decided to push the lawyers out of the way and simply collaborate, focusing on defining how we would work together rather than defining detailed scope and change processes. This collaboration was so successful that, not only the product release plan met every milestone, but also that the President of PSWF became one of the partners at P3M Solutions. Collaboration really worked!  

Finally, the main change structured organizations need to make to adopt agile approaches is a five letter word: trust, which happens to be the cornerstone of agile. Trust means delegation of authority to make decisions, from executive level to management level, to people that can be part of the team and sit with them day in day out. Trust means understanding that not all requirements will be met, but the product will deliver the capability the business needs to realize the expected benefits. The output of the project will not likely have all the “bells and whistles” initially thought for it, but will have the “fitness for use”, what the business needs, that “good enough” solution that gets faster to market.

Organizations that adopt agile approaches and Agile-Stage-Gate and also adjust their supporting functions to remove roadblocks will be in an advantageous position to compete, achieving faster “time to market” Instead of talking about innovation, organizations need to adjust their governance structure, processes and organizational culture in order to foster and not quench innovation. Organizations can decide to restore paradise, or wait until hell freezes over.    

 

Fernando Santiago is Managing Partner at P3M Solutions, a firm that develops project and portfolio management software and provides consulting and training in project management and IT governance.  P3M Solutions has a strategic alliance with RG Cooper & Associates to represent Robert Cooper and Agile-Stage-Gate in the Latin American market.

skeleton

Is Project Management a skeleton from the Industrial Revolution?

The pace of adoption of innovation in project management

It is the end of October now, and as Halloween approaches, we drive by graveyards, open tombs, and skeletons, some of them funny, some not so much. In some cultures, like in Mexico, "Dia de los Muertos" is the day to honour the dead. In North America we dress up our kids in costumes and walk the streets for candy, Mexicans take food and tequila to the cemeteries and party all night. Hey, we Latinos can make a party out of anything!

Skeletons are innocuous when they remain in their coffins. The problem is when they pretend to be alive and, even worst, when we listen to them, as if it were still their time, when it is not.

Project Management has been accused of being a thing of the past, a dinosaur, a cadaver that enjoys surprising health. In 2002 a group of developers got together at a ski resort in Utah and came up with the Agile Manifesto, which was an elegant way to tell project managers to get out of the way and let developers do what they do best: build software without the interference of project management and project life cycle processes and rules.

While this is not a call to go wild and back to "cowboy development", it should be interpreted as a wake-up call.  Software developers, computer engineers, etc; are usually the bright kids out of high school, the nerds with a cap and propeller. However, the question is: what do you call a nerd twenty years after graduating from high school? The answer is "boss".

Project teams get these bright kids who, after college or university and years of experience, are even smarter. And what we do is treat them like complete idiots. We, project managers, need  to tell them exactly what to do, otherwise they will not be able to figure it out on their own. After ten years of agile practices and even PMI jumping on the bandwagon to cash in with a certification (PMI: agile was never about project management to start with), it is now widely accepted that business analysts, developers, testers, are not idiots after all.  All we need to do is tell them what the goal is, and when it needs to get done, and they will find the best way to do it.  Like in my favourite line in Jurassic Park: "nature will find its way".

However, many project managers, and even methodologies, still cling to the past. And this is not about agile VS waterfall; it is about management VS leadership, it is about telling people what to do VS facilitating the conditions for the team to excel; it is about taking the driver seat or the back seat, and let the team drive.

Going back to the theme of this article, it is interesting to draw a parallel with the industrial revolution, which was triggered by the great invention of the eighteen century, the Steam Engine by James Watt, a Scottish instrument maker who created an innovation that changed the world. For centuries, industrial facilities had depended on the flow of water from a river to draw power using a wheel connected to a number of axles through a complicated arrangement of pulleys and gears that were in movement all the time. Each workstation only had to hang a leather belt from the overhead axle and they were connected to the source of power. This model had many problems: first, it was all or nothing for the whole plant; second, and most important, it depended on the flow of water: no water, no power, and in North America and Europe, water during winter time tends to freeze, so mills had to stop until the spring, when the problem was to control the excess flow from the meltdown.  With Watt's invention, none of these problems existed. All they had to do was store sufficient water, and here is where the "mill pond" comes from, so water could be drawn and boiled into steam. Although not perfect, it was a better solution. Not the best job for those shoveling coal day in day out, and fires were frequent, but it worked. So mills all over the world installed steam engines, which powered the same mechanism of axels and pulleys they had before, and the industrial revolution came to be, kids were exploited, Dickens wrote his books, fortunes were made, and people got used to cheap goods they could take home. Life was “good”.

In the nineteenth century, another Brit, Michael Faraday, an Englishman this time, invented the electric motor. It was cleaner, safer, and more dependable than the steam engine. So factories all over the world quickly adopted the new technology, replacing the obsolete steam engine with a huge electric motor. Nothing changed, it was just cleaner and safer, but the way of doing things was still the same.

It took seventy years, or three generations, for industry to realize that the advantage of the innovation they had adopted was the ability to install small electric motors at each work station, so they could be turned on and off at will, and speed controlled to suit the task at hand. Seventy years to realize the potential of technology, of the innovation they had already adopted. Do you think it is silly? Keep reading.

The history of project management is surprisingly similar. As a discipline, project management emerged after the Second World War in the aerospace and defence and engineering and construction sectors. During the fifties, sixties and seventies, mainframes became affordable for both the private and public sector. Project management software came to be in early versions of products like Open Plan, Artemis and Primavera, which are still around in some form. There were no PC's at the time, no networks, no tablets or cell phones; only a mainframe in a protected environment, with raised floor and a group of chosen ones who could tame the beast, taking punched cards in and coming out with white and green reports. That is the world I got to know when I started my career as a project manager in the oil industry and then in the engineering consulting sector, in the late eighties.

Because of the central concept dictated by the mainframe, the model worked as follows:

  • A command and control approach to program and project management, with project managers cracking the whip every five minutes or so, pushing teams of hundreds of engineers and draftsmen creating blueprints and other documents. It was the industrial revolution all over again, just cleaner.
  • Engineering projects, as predictable as they are, can be defined in advance in an excruciating level of detail, so the mainframe was fed with schedules that had thousands of tasks. Updates were fed to the mainframe and we got back reports with the state of the project. Considering how primitive the technology was, we did pretty sophisticated project management. Today I have to smile when students and project managers tell me that Earned Value is complicated. We did it back then with punched cards, pencil and paper. We had no PC's, no Excel, just paper and pencil, and a brain.
  • While this was happening in the aerospace and defence and engineering consulting, IT was just getting started with project management. As software companies and IT departments in banks and insurance companies (some were called IBM Department, believe it or not), the need for project management became obvious. As projects got bigger, more complex and difficult to manage, IT turned to the "pros", the hard core engineering PM's, to help with project management. Engineering Consulting firms saw the business opportunity and spun off firms to sell this know-how to industry. I happen to work in one of those firms, and project management was our product to sell.
  • In the eighties and nineties, many PMs decided to jump ship and got hired by IT departments and software companies. I was one of them, and we did what we knew best: we replicated the model that worked so well in engineering consulting, and it failed miserably.  First of all, engineers are easy to manage: us engineers tend to be structured, predictable, we follow process and rules. A command and control model works well with engineers. On the exact opposite, software engineers, architects, developers, are a different breed: they are artists, they are creative, they are constantly coming up with new things. Some of them can be "prima donnas". A command and control model doesn't work well with these people, but we tried anyway, and we failed.  In the early nineties, the Standish Group surprised the world with the "Chaos Report", a research project based on thousands of IT projects all over the world, and it was not pretty: only one out of three projects in IT was completed within a reasonable time and cost variance and meeting scope. The vast majority of IT projects were outright failures, with average overruns of 200% and up, severely behind schedule and over budget.
  • Continuing down memory lane, in the eighties and early nineties we got a number of innovations that had great potential to improve project management in IT: the PC, the network and, you guessed it, Microsoft Project.
  • So what did we do with these new capabilities? We made exactly the same mistake that was made in the eighteen century with the electric motor: we replaced the mainframe with a PC on steroids, or so it seemed at the time, installed MS Project, and ran the show exactly the same way as before, only cheaper. We put schedules with thousands of lines through MS Project, and it choked and crashed (twenty years have passed and still does...). We printed the schedules, some even printed PERT diagrams and used them as fancy wall paper to impress the bosses with the sophistication of the project management profession. These schedules and PERT diagrams stayed on the walls for months and years, and who would even think about updating them; that would be too much work. We were material not for a Dilbert strip, but for a complete book.
  • As we geared towards Y2K (for the younger generation, we thought that computers would stop working when clocks would go from 99 to 00, Terminator would come and destroy the world as we know it; at the end, nothing happened, but there was plenty of work for all of us for a few years).  Shops were busy again, the dot com era was booming and IT was the place to be.  The problem, and there is always a problem, is that projects were less predictable every day, as we moved from mainframe to client-server to web, things were just impossible to predict in advance. This is when and why agile emerges, and it teaches project management a lesson or two.

For those who have braved the history lesson and made it to this point, the good news is that IT is finally starting to get its act together. Today the reports from the Standish Group show improvement, while there is still a lot to be done, results are not as bad as before. It took us twenty years, at least not seventy years like two centuries ago, to realize the potential of having a scheduling tool available throughout the organization, and information flowing across projects, programs and portfolios. PPM tools now provide the functionality to support smaller teams, even agile teams, each one accountable for a deliverable or work package, with its own schedule and, most important, self-managed, with a project manager that is no longer a dictator but a facilitator. This is not exclusive to agile, and it is applicable to even pure waterfall projects.

The key idea is to relinquish the need to have centralized command and control, and delegate to teams, empower the leaders and their teams, give them a date they have to make, explain to them how their piece fits in the overall project or program, and why the date is important, and they will deliver.

Remember: you have the brightest kids in your teams. Don't treat them as idiots. If you can't handle the change, you are still on time to pick up a skeleton costume for Halloween or, even better, "Dia de Muertos" in Mexico. And don't forget the tequila: you are going to need it.

Fernando Santiago MBA PMP CSM

Consultant in Organizational Project Management

Thursday, 04 September 2014 03:44

So you think you can dance?

High energy teams are not exclusive to agile. One of the principles of agile approaches that has a strong contribution is time boxing, as everything in agile has a fixed duration: the number of weeks for the iteration/sprints, the duration of the daily scrums, planning, retrospectives, etc. Time-boxing establishes cadence and, after two or three iterations, the team learns how much output they can produce. In addition, having short term goals keeps the teams at a constant high pace and productivity. Many project managers today see the traditional waterfall approach as a dinosaur, a dysfunctional approach that should be avoided. This is simply not true, as waterfall is not only a valid approach but the only option for certain types of projects that don’t fit agile. The implementation of COTS (commercial off the shelf software) relies heavily on scheduling, as training sessions need to defined, rooms booked, etc. There is no way out: you need a schedule, and a detailed one. This just can’t be done using agile. Using waterfall is not equivalent to a low-energy team. There are no “sticky notes”, colourful project walls and you don’t feel proud to be a pig (yes, in agile being a pig is a good thing) and you can call non-team members chickens. While not as colourful, a waterfall project can be high energy and lots of fun. Cadence is one of the strategies that turns a waterfall project into a high energy team, and is defined at two levels: • A weekly cycle for execution: in essence, this is similar to a weekly sprint, without the rigour of planning and retrospective that agile has. The weekly cycle starts with the gathering of information on actuals at the end of the week, usually Friday afternoon or Monday morning. The PM updates the schedule with these actuals and assesses the situation of the project: is the next milestone (always the next milestone) still on track? Then the PM meets with the team with the schedule visible to everyone, so the team can visualize the situation, come up with ideas to bring the milestone back on track if needed. Adjustments to the schedule are done “live” by the PM in front of the team so, at the end of the meeting, everyone leaves with a clear idea of what needs to be done this week to stay on track. After the meeting the PM makes final adjustment to the schedule and generates the weekly status report, which becomes a by-product and not the main purpose of the weekly cycle. • Milestones that keep the team at the right level of effort, not too distant that allows for slacking for a week or two after a milestone is achieved, similar to what happens in college after mid-terms. Milestones should not be to close either, because if the team achieves a milestone every few weeks, they become meaningless, losing the power to motivate as a visible and common goals. Research done a few years back by the PMO Executive Council identified 40 drivers of excellence in project management, and the number one driver was “Obsession with the achievement of milestones”. As a side note, “Following Project Management Practices” was the last on the list, still important, but not as much as other drivers. There is no “rule of thumb” to define the number of milestones or the interval between milestones, but there are some “old dog tricks” to plan milestones: o Make your milestones aggressive but achievable, and always protect the milestone with a buffer or contingency. o Spread the effort in a way that the early milestones are easier to achieve, because the project is still ramping up, resources are not all on board, etc. The middle section of the milestones should be very demanding for the team, as this is the time to make progress and plow through work. The final section of the milestones should be easier to achieve, as the final stretches of every project always discover new things and, there is less room to maneuver as you approach the final milestone. In particular, the first milestone needs to have a high degree on confidence. Why, because it will become the prophecy for the team on whether they can achieve the milestones or not. As Seneca, the Greek philosopher said “Whether they think they can or cannot, they are right”. Cadence is a fundamental principle of project management which, as discussed earlier, comes “built in” in agile approaches. When using waterfall, cadence will be a result of planning, for milestone definition, and a project management plan for execution. So you decide: tango or cha-cha?