Lately, I blogged about management behavior that will make or break a robust agile implementation. I mentioned that agile transformations are only likely to succeed if heavily supported by the management. It is a prerequisite for a robust agile implementation that managers act according to agile principles themselves, and:

1. Are available for timely strategic decision making as required
2. Provide the frame for true delegation of operational decision power to the operational level
3. Foster an environment of trust at all levels in the organization
4. Accept that errors will happen (and understand that they always did)

Only four bullets, but all easier said than done.

Here is why:

Bullet #1 – Timely Strategic Decision-Making:

Top-level managers often do not see the necessity to involve themselves in projects on an ongoing basis. Yes, they allocate (a lot of) money to projects, and yes, they do get upset, when projects overspend or get delayed, but usually they do not see themselves as more than an escalation point for their Project Managers.

They may be dealing with change requests once damage has occurred, but they don’t realize that they could have helped prevent the damage from occurring, by being more directly involved in the projects they have invested in. By simply being available for “on demand” decision-making.

Some agile methods try to cover this lack of business involvement by having a Product Owner (PO) representing the business with all decision power vested in him or her. This role, however, is one that I have never truly seen work as intended. Here are a few reasons:

1. Politics: Managers will not leave decision power to others
2. The organization do not trust the PO to make the right decisions
3. The PO do not understand the purpose and nature of the role
4. The PO has not been educated to fulfil the role

The result of lacking will or ability from the management layer to involve themselves in projects, and helping with timely decision-making, is suffering agile projects.

Bullet #2 – True Delegation of Operational Decision Power:

Many projects fail. That might be why there is resistance to delegate decision power to Project Managers (PMs) or to POs as “their results prove that they are not able to handle that kind of responsibility”.

However, as long as inexperienced, not sufficiently trained PMs are asked to manage projects that are too complex for them to handle, it is no wonder that projects fail. Here are a few reasons why managers delegate projects to PMs that are not ready for it:

1. Managers do not realize that (IT) projects are complex by nature
2. The more experienced PMs are not available, but they still want to start the project
3. Many believe that as long as a project method is in place, all is fine
4. There is a “how-hard-can-it-be” attitude when it comes to project management

However, complexities on projects typically do not originate from systems but from people, politics, and organizational behaviors. How PMs might handle these complexities is not explained in any method.

Not understanding the complex nature of projects will, not surprisingly, lead to poor project results. Much would be achieved if organizations would start having look at:

• How they allocate PMs to projects depending on skills vs. project complexity
• Whether their project method is fit for purpose (it is usually too complex)
• The way they educate their PMs internally. (A certification is not enough)

Bullet #3 – Fostering An Environment of Trust:

Having seen many projects fail, managers may not trust their PMs to do things right. Therefore, they insist on having the last say in project matters although they are the least involved, and therefore cannot make the best decisions. Other than poor decisions, which can be bad enough, this causes waiting time, lost resources, and delays.

Organizations do buy in to agile methods, but they often do not realize what big implications this will have on organizational behavior. If you work in a control-and-command type organization, the shift to agile where trust is a prerequisite, may be too big a leap and will not work.

If, on the other hand, organizations really want to realize the benefits of going agile, they must analyze exactly how and where changes are required from top to bottom in the organization. Agile comes with a price in terms of behavior. Here are some reasons why this price is not willingly paid:

1. Managers do not want to move away from the systems they have used for many years.
2. Known false sense of security and poor results feel more comfortable than trying “the agile unknown”
3. Company culture and politics may hinder a trusting environment. The transformation is simply too difficult
4. Managers don’t see their role in facilitating the transformation to agile and walking the talk

Bullet #4 – Accept That Errors Will Happen And Always Have:

Projects are taking organizations to where they have never been before. No matter how thorough you are and how well you plan, you cannot predict the future – particularly not if the future lies years ahead. Therefore, project teams will make mistakes, estimates will be wrong, contracts may be bad, etc.

Furthermore, project teams, are often forced to deliver under conditions regarding scope, cost, or time that everyone knows are too optimistic. Thus, you are planning for disaster from the very start, and to keep your budgets, deadlines etc., you start cutting corners. You cut quality, reduce test activities etc. This will also result in errors. Errors that could have been avoided by setting realistic project goals.

Error-free projects do not exist and never have. With agile techniques, you can avoid many errors from getting out to customers or end-users, but to get to that point, managers must realize that they must:

1. Support their agile teams by helping the whole organization  becoming  more agile and by being agile themselves
2. Stop forcing unrealistic project baselines on their project teams. Reality cannot be changed anyway
3. Not expect the impossible. Error-free systems or projects do not exist, but insist on building quality into your project processes
4. Facilitate a learning culture and allow time for reflecting on improvement opportunities

It may sound like quite a mouthful, but if the goal is increased project success, you have to do something different tomorrow compared to what you do today. If nothing moves, nothings changes.