Tuesday, April 25, 2017

The reverse triple constraint of troubled projects

Project Management Reversed Triple Constraint Triangle
Assuming you suspect or know that one of your projects is in trouble the first step is always an extensive project review. After such a review you hopefully have the necessary information for decision-making as well as the team’s support for the recovery of the project.

It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to the stakeholders. When the project first began, the triple constraints most likely looked like what you see in the figure below.

Project Management Triple Constraint Triangle

Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes distressed, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image/reputation as shown in the figure below.

Project Management Reversed Triple Constraint Triangle

This happens almost every time I join a troubled project. After focussing on these the project actually runs a lot smoother and high-value outcomes are prioritized and supported. So the big question is why don't we start projects with the reversed constraint triangle? Why put our image and reputation on the line by letting it come that far? Why work on things that obviously do not have such a high value because when it comes hard on hard they are not needed? Why make the quality first a priority when we already feel the pain of bad quality?

The funny thing is that agile methods like Scrum try to do exactly this. Focus on value and quality. This automatically helps your image/reputation. When the time in a Scrum project is fixed this automatically means that cost is fixed as well, but your scope is flexible. In other words, only the most valuable things are done in a good quality.  When the scope is fixed, your time and costs are flexible. Still, the team will start working on the most valuable things first and you can stop the project at any time, and have valuable results. No high-risk big bangs, valuable results are delivered every sprint.

The reason I say that agile methods try to do this, and not actually do this, is because they are hindered in most organizations. The acceptance and adoption of new ways of budgeting and planning for projects lay way behind of the acceptance and adoption of using agile methods in projects. And those agile projects are suffering because of it.

Read more…

Wednesday, April 19, 2017

8 Signs of a troubled project

When you’re dealing with a troubled project, there are usually a number of red flags surrounding you. This article is written from the perspective of a senior manager (for instance, members of the Steering Committee).

All of us have endured troubled projects that didn’t accomplish their intended business goals. Such watermelon projects, which come across as green on our project dashboards but are, in fact, red, upon closer inspection, are very typical in a company’s project portfolio.

Generally, during the failure of a project, the last people to find out are those in senior management. However, at some point, failure becomes readily apparent. When the scenario gets to that point, you might not have any other choice but to start everything over from scratch. What separates failure from success is isolating the red flags of a troublesome project early. Here’s a brief synopsis of early signs to look out for in order to prevent a disaster.

1. Always Green Lights, Minimal Activity.
Most of us are known with labeling a project as green when they are budgeted and scheduled; yellow when the project is under the gun, and red when the project is late and over budget. Maybe your primary project has been reporting green for a while, but strangely, there’s been minimal activity associated with it. That’s a strong indication of the project being in dire straits.

2. Many TBD’s (To Be Determined).
Proper issue and risk management is vital for a project to be successful, but is typically neglected. If your primary project has surpassed the early stages, yet marking plenty of TBD’s in the “resolution” column for issues and risk, then it’s more than likely facing a series of problems, regardless of whether a schedule discloses it.

3. Avoiders.
The charge leader in your primary project might be a business line manager or a formal project manager. No matter who they are, your gut is telling you that they’re avoiding you intentionally. Maybe they’re not seen in meetings, they walk the other way when they see you coming, they don’t pick up their phones, or aren’t sending you status updates. Chances are you’re being avoided because the project is in trouble.

4. Problematic Trends.
An up-to-date Product Backlog tells you exactly what has been accomplished for what money in what time. Or methods like EVM (Earned Value Management) to identify the progression of a project could be used. They contrast real results by what was intended, expenses incurred, and time allocated. While your projects might not use these methods, you can catch substantial drops or increases in expenditures, large modifications to work being sent, or immediate alterations to a timetable without new dates. Pay close attention when this is the case.

5. Non-Progress Reports.
You’re smart, so you have consulted your project manager about offering weekly status reports. That said, those reports don’t show any sign of progression, ironically. More specifically, if you’ve obtained a couple of weekly status reports without chronicled progression, chances are your project is either in trouble, or about to be.

6. Failure to Display Physical Results.
During the timeline of your project, you request a demonstration or assessment of finished work so far (Sprint Reviews for example). However, the meeting for such reviews is regularly postponed and rescheduled, perhaps by days or even weeks. Further, you’ve made a spontaneous visit to the project leader, but instead receiving a demonstration of work done you are getting documents, PowerPoint presentations and a lot of hot air talk. If this is the case, you probably have a troubled project on your hands.

7. Lack of Communication.
Poor engagement, whether it’s informal and formal, is a red flag. If the stakeholders, including users and group members, aren’t interacting with one other, guess what? You’re facing trouble.

8. Instinct.
You are mindful of what projects are high-risk. When your primary project is mentioned, you know something is up, even if you can’t pinpoint what. By trusting your instincts, you’re inclined to discover something noteworthy.

Be mindful that these red flags are just signs, and nothing more. They don’t suggest failure of a project, or that people have failed. Each project endures its highs and lows, and you simply have to account for them. The red flags might suggest that a project is in need of proper attention from executive management.

Managers are encouraged to do nothing more than observe closely for a couple of weeks before taking action. A detailed project review is required when no tangible improvements have been realized in this period.

Read more…

Friday, April 14, 2017

LeSS and Scrum Alliance against SAFe?

So last week the Scrum Alliance announced a partnership with LeSS. How this partnership is going to look like was not part of the announcement so we will have to wait for this. But I think it was a smart move for both the Scrum Alliance and the LeSS company. Too late, but smart never the less. A few random observations from my side:


- Scaling Agile / Scrum is becoming a more and more important argument for certification companies.

- Scrum.org (Ken Schwaber) created it's own scaling framework Nexus. See my Nexus review.

- SAFe is only about scaling agile. See my SAFe review.

- LeSS is only about scaling Scrum. Hence a good add-on for the Scrum Alliance since it is about Scrum only, and no other agile methods. See my LeSS review.

- Scrum Inc (Jeff Sutherland) created its own modular scaling approach Scrum at Scale. See my Scrum at Scale review.

- Scrum Alliance had no answer to the scaling question. This would be solved now.


- SAFe is selling very successfully in the enterprise world. When talking about the number of times a scaling framework is used SAFe is absolutely on top. See 11th State of Agile report for international numbers and Trends and Benchmarks of SwissQ for Swiss numbers.

- Scrum.org is very focused on software development only and seems to be very successful with it. The quality of their certifications is in my humble opinion better than those of the Scrum Alliance. This because of standardization and hard questions, were those of the Scrum Alliance are hit or miss depending on your trainer and own efforts and interest to learn.

- Scrum Alliance is very focused on selling certifications, and this only on a ScrumMaster / Product Owner / Developer / Coach level. This meant that management was completely left out of the picture. But they are usually the ones that are deciding on what framework to implement.  SAFe understands this very well. The Scrum Alliance tries to catch up with Agile Leadership certifications, but this is also the wrong thing to address when it comes to enterprise selling.

- LeSS is not much used in companies. There are a number of use cases, but there is not a large market traction. The partnership with Scrum Alliance could change this.

- SAFe is entering the certification market of Scrum.org and Scrum Alliance with their Advanced Scrum Master Certifications.


- SAFe has defined a very clear path to implementation with its implementation roadmap. There it addresses the very important point of training all executives, managers, and leaders even before you train your teams. Get their buy-in and understanding. This is absolutely the right way to do. Again, they seem to understand how the enterprise world works.

- LeSS also has written about how an implementation (they call it adoption) would work best. It is not as clear and detailed as that from SAFe, but it makes sense and is a good start.

- Scrum Alliance actually hardly mentions how you could implement Scrum in your organization. It's training and certification only focus on how to run a single Scrum team. This is a huge gap in their training.

- Scrum at Scale is not a framework and not something you can implement. But it is an incredibly helpful tool to help you create your own scaling strategy and/or framework.

- SAFe (like Scrum) is very prescriptive, so it easy to start with. All steps are defined for you. The way it is defined and how prescriptive it is takes away the Agile part of it. You could easily argue that SAFe is not Agile at all anymore.

- In order to successfully implement LeSS, Nexus or even Scrum, you will need significant changes in your organizational structure. With SAFe you do not, it is placed on top what you have, so it is easy for management to decide this because they do not have to change.   

What would I implement?

I already have written down my "Essential rules for Scaling Agile" in a previous post, and I still stand by them. But when I would be forced to select a framework for a product oriented company I think LeSS can be of high value when a goal of the company is becoming agile. When it is a company with a traditional project culture and is saying it wants to be agile, but is actually liking the status quo than it is far much easier and probably more successful to implement SAFe. 

It seems to me to be a compromise between the abstract desire for more agility and the typical constraint that the enterprise can get away without more agility. I appreciate its attempt to acknowledge the realities of the typical enterprise, but it seems to give enterprises an excuse not to change very much. I don't like it, but I understand why it exists and seems to be selling very well. The verdict is still out if it actually works very well for all those organizations.

Read more…

Tuesday, April 11, 2017

The Ultimate Project Review Checklist

The Ultimate Project Review Checklist
After reading the book "The Checklist Manifesto: How to Get Things Right" from Atul Gwande I was thinking about a number of checklists that I am using on a regular basis myself.

A few of them were created by others (see for example the Unofficial Scrum Checklist and the ScrumMaster Checklist), but I also created many of them myself. This eBook is one of those. It is the checklist I use as a base for my Project Reviews. Like every checklist, you have to adapt it to your specific situation, but I think you will find it very usefull as a base for your own Project Review. It contains 22 different categories and more then 140 different checks/questions.

Focus is on software development, financial modelling, business intelligence and data migration projects, but most of it is valid for other projects as well. Since I use almost exclusively agile techniques like Scrum, Kanban, XP and LeSS in my projects the list is leaning in this direction, but I tried to keep it very method agnostic. Meaning this list is just as usefull for waterfall projects as for a typical agile Project. You can get a free copy below.

The Ultimate Project Review Checklist

Get your Ultimate Project Review Checklist

Read more…

Sunday, April 09, 2017

Your real project costs

At the top of the budget hierarchy in most companies and organizations stand two major kinds of budgets, a capital budget, and an operating budget. These two kinds of budgets do not overlap: they handle distinctly different spending categories. Capital and operating budgets, moreover, are built through different budgeting processes, by different managers, and they use different criteria for prioritizing and deciding spending.

A capital expenditure (CapEx) is defined as an expenditure contributing value to the property and equipment of a business. It is an expenditure toward capital assets, as contrasted with spending that covers operating expenses (OpEx) or purchase of investments unrelated to the company's primary business.

Many projects I am involved in only looked at the potential (and mostly theoretical) business benefits and the CapEx cost upfront. They "forgot" or "ignored" the OpEx side of the project. These can be very high compared to the initial project costs. Especially when you implement a new technology/product in your company where there is no team yet that understands it and is able to run it without help from outside.

Even when working with both CapEx and OpEx a number of "hidden" costs are easily forgotten, hence the concept of Total Cost of Ownership (TCO) for 3 or 5 years.

Let me start with a quick definition of CapEx, OpEx, and TCO.

Capital Expidenture (CapEx)

CapEx is an expense where the benefit continues over a long period, rather than being exhausted in a short period. Such expenditure is of a non-recurring nature and results in an acquisition of permanent assets. It is thus distinct from a recurring expense.

For tax purposes, CapEx is a cost which cannot be deducted in the year in which it is paid or incurred and must be capitalized. The general rule is that if the acquired property's useful life is longer than the taxable year, then the cost must be capitalized. The capital expenditure costs are then amortized or depreciated over the life of the asset in question. Further to the above, CapEx creates or adds basis to the asset or property, which once adjusted, will determine tax liability in the event of sale or transfer.

Included in capital expenditures are amounts spent on:

1. acquiring fixed, and in some cases, intangible assets
2. repairing an existing asset so as to improve its useful life
3. upgrading an existing asset if it results in a superior fixture
4. preparing an asset to be used in business
5. restoring property or adapting it to a new or different use
6. starting or acquiring a new business

An ongoing question for the accounting of any company is whether certain expenses should be capitalized or expensed. Costs which are expensed in a particular month simply appear on the financial statement as a cost incurred that month. Costs that are capitalized, however, are amortized or depreciated over multiple years. Capitalized expenditures show up on the balance sheet.

Most ordinary business expenses are clearly either expendable or capitalizable, but some expenses could be treated either way, according to the preference of the company. Capitalized interest if applicable is also spread out over the life of the asset. The counterpart of capital expenditure is operational expenditure (OpEx).

Operating Expidenture (OpEx)

An operating expense, operating expenditure, operational expense, operational expenditure or OpEx is an ongoing cost for running a product, business, or system. Its counterpart, a capital expenditure (CapEx), is the cost of developing or providing non-consumable parts for the product or system. For example, the purchase of a software involves CapEx, and the annual maintenance fee, power, and maintenance costs and people running the software represent OpEx.

In business, an operating expense is a day-to-day expense such as sales and administration, or research & development, as opposed to production, costs, and pricing. In short, this is the money the business spends in order to turn inventory into throughput.
On an income statement, "operating expenses" is the sum of a business's operating expenses for a period of time, such as a month or year.

Operating expenses include:

1. license fees
2. maintenance and repairs
3. people who operate the software
4. training
5. first, second and third level support

To summarize the key differences between CapEx and OpEx are:

Total Costs of Ownership (TCO)

Total Cost of Ownership (TCO) is an analysis meant to uncover all the lifetime costs that follow from owning certain kinds of assets. As a result, TCO is sometimes called life cycle cost analysis.

Asset ownership brings purchase costs, of course, but ownership also brings costs due to installing, deploying, using, upgrading, and maintaining the same assets. These after-purchase costs can be substantial. Consequently, for many kinds of assets, TCO analysis finds a very large difference between purchase price and total life cycle costs. And, the difference can be especially large when ownership covers a long time period. As a result, TCO analysis sends a very strong message to corporate buyers, capital review groups, and asset managers:

Those who purchase or manage IT systems have had a keen interest in TCO since the late 1980s. At that time, IT industry analysts began publishing studies showing a very large difference between IT systems prices and systems costs. And, not surprisingly, these soon got the attention of IT vendor sales teams and marketers.

Competitors of large companies, for instance, used their own TCO results to argue that the systems of these large companies were overly expensive to own and operate. This kind of argument is possible because the five-year total cost of ownership for major hardware and software systems—from any vendor—can be five to ten times the hardware and software purchase price. The same is currently happening with the move to the cloud.

TCO for large projects and purchases is very helpful in the following:

1. Budgeting and planning
2. Asset life cycle management
3. Prioritizing capital purchase proposals.
4. Evaluating capital project proposals
5. Vendor selection.
6. Lease vs. buy decisions.

Why does it matter?

In order to make a good decision about starting, continuing or ending a project you need a good overview of the costs of the project. Just using the direct costs of the project are usually only a small part of the truth.

Consider TCO instead of project costs when making decisions!

Read more…