Agile Management

Tips on managing product development and engineering by John Levy, consultant, expert and author of “Get Out of the Way!, An executive’s guide to creating timely, innovative and relevant products.”

Risk Management in IT

April 25, 2012

Risk management is a key area for financial leaders.  When we look at IT development projects, we’re usually focused on opportunities rather than risks.  But IT investments have risks beyond security and privacy issues.  Project failure can lead to losses even beyond the intended investment.  Here are seven ways to look at IT development projects from a risk management point of view.

1. IT Operations and IT Development must be managed differently. Development is Engineering and must be managed as such. In particular, this means that there must be a certain amount of experimentation to find the best implementation. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Success criteria for IT Operations and IT Development are also different. Development should be measured based on expected ROI plus the strategic value of the project.  For externally visible development, time-to-market and accuracy in delivery against market requirements are also relevant measures.  Operations should be measured on predictability of spending and on Quality of Service.  Operations measures should undergo regular and consistent assessment of their relevance to the business.

3. Most failures in IT Development are caused or compounded by management errors. Very few failures are due to technical inadequacy. The probability of future failures remains undiminished so long as the management errors are not addressed. Examples of these errors include not planning for scalability or not emphasizing modularity of the implementation.

4. The cost of failure in IT Development nearly always exceeds the allocated budget for the activity. Project failure has consequences beyond the immediate failed project, both for people and for other projects.  For example, one late project often cascades through to lateness of follow-on projects.  Another risk factor is the loss of key people when a development project fails.  It is rare to find IT management mitigating this people risk immediately on learning of a development failure.

5. Failures and losses in IT Operations involve directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less familiar, to Operations managers.

6. IT management should be able to communicate to top management the tradeoffs in IT Operations and Development, so that they understand the strategic implications of decisions in IT.  Operational budget must not be the exclusive determinant of IT decisions. In general, the CIO should not report through the CFO.

7. Multi-year planning is essential for both IT Operations and Development. A roadmap for upgrade and integration of resources and services is necessary, even if it must be revised multiple times per year as new services and equipment are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.

If these ideas resonate with your experience – or if you disagree, please add your comments below.

These thoughts were triggered by a recent paper, “Risk Management Failures” (http://tinyurl.com/7ew4t79) by Prof. René Stultz of Ohio State University, published by Cornerstone Research in 2009 (http://cornerstone.com).  With thanks to Andre Neumann-Loreck for his feedback and comments.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,

Trust, truth and talking things through

April 10, 2012

Collaboration thrives on trust, truth and a willingness to talk things through.  When these elements are present for people in a team or in a department, those people take responsibility, use their authority wisely, and develop a climate of openness.

Here are key principles and other aspects of each of these elements.

Trust

I trust you if you speak and act with respect and maintain that respect when you communicate with others about me

Team members gain trust by doing what they say they will do.  But even more important in gaining trust is being respectful when speaking to a person or to someone else about a person.

In addition, a manager should always defend the team’s boundaries.  This includes alerting the team when there is a potential conflict with another team or manager and backing up the team when it needed.

Truth

If you believe you’re never wrong, you should not be on a team or in management.

Truthfulness is, of course, saying what’s true and not saying what’s false.  But much more important is being willing to own your own mistakes and misunderstandings.  By being open to correcting yourself, you make space for me to do the same.  You also make willingness to adapt and learn part of our shared culture.

A lot of the work of business is finding out what’s true – about a market, about a product, or about the world.  As long as we’re open to learning, which means there are things we don’t know, we encourage real inquiry that leads to knowledge and good decisions.

Talking things through

 “Talking things through” is being willing to address conflict.

Since conflict is inevitable, we need healthy ways to deal with it.  The best way is to acknowledge its existence right away, but not by making the other person wrong.  We can state what we see as disagreement without disrespect or rancor.  Start from assuming that the other person has a valid reason for their view.  Then start listening rather than arguing.

While compromise is one way to resolve conflict, there is a better way.  Begin by understanding the values and intentions of the other person.  Then search for ways to resolve the conflict while advancing both your own and the other person’s values.

What about incentives?  People who are collaborating successfully need very little additional incentives, because the process of collaboration – and the successes it generates – are rewarding enough.  Create an environment where there is trust, truth and talking things through, and you need only get out of the way.

Filed Under: Agile Management Tagged With: , , , , , , ,

It’s actually easier to do the right thing

March 26, 2012

The right thing is to plan, organize and execute with long-term results in mind.  But nearly every manager is so driven by short-term metrics that they fail to account for longer-term effects of their decisions and actions.  As a result, they accomplish less for themselves and for their organizations, making them less effective and less competitive.

Here are three ways to incorporate longer-term thinking:

1. People working for you know when they’re being put at a disadvantage due to short-term thinking.  For example, if you won’t spend the capital needed to buy the right tools, they’ll keep working, but they’ll resent both the inefficiency of the work and the lack of regard it shows for them as workers.

People will find ways to correct problems and to self-organize to be more efficient if you will only give the room to operate.  This includes trusting them to find the best way to organize and giving them enough budget to execute the plan.    Your main contribution after that is to give them enough of the bigger picture so they know how their work fits in with your objectives.

2. If you’re committed to personal growth, then you need to track your effectiveness over a longer term.  Your monthly or quarterly objectives are the table stakes in this game.  Cranking out regular results will guard your job, but it won’t make you ready for a larger role unless you include a vision of what’s possible in the longer term

If you want to be seen as an emerging leader, then you have to champion longer-term growth and improvement.  To do that, you’ll need to solicit feedback and actually listen to it.  And you’ll need ways to identify short-term objectives that are actually causing damage to longer-term results.

For example, a client company refused for years to convert to better programming language tools because changing tools would make the first project to use them take longer.  As a result, they went for years at a disadvantage compared to their competitors.   Eventually, they changed – when they merged with a competitor that was already using the tools.

3. In some areas, such as product development, experimentation is essential.  You may think that Engineering is a deductive, forward-only process; but in fact a lot of development involves eliminating the unworkable by trying it out.

Once you realize that experimentation is part of the process, you stop regarding abandoned directions as a waste of time and resources.  In fact, experiments lead to better decisions and stronger platforms on which good products are based. Since the result of having stronger platforms is not visible until the next product, you could harm your product line significantly by insisting on maximum-speed implementation.

The alternative to backtracking after an experiment is to fall off a cliff – with failure of the process.  It’s better to insist on high-quality, incremental progress.  And how do you know you are seeing incremental progress?  You have to have a longer-term vision and plan to measure it against.

Once you have the vision and the plan, it’s actually easier to do the right thing.

 

How are you keeping longer-term results in mind?  Post your comments below.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , ,

Success always looks easy

March 13, 2012

With all the news about IT projects that go bad, you would think that we’d hear more news about projects that go well.  Then we could just copy down the “best practices” that led to the success and – voilà – our projects would come out perfectly every time.

But life is not so simple.  While we can enumerate key problems that led to failure by analyzing projects, it is much harder to point to one factor and say “this is what made this project successful.”  Success depends not only on avoiding the pitfalls, but also on bringing together all of the essential project elements.  Sometimes those elements are not so easy to identify.

Example 1:  I once struggled for 7 months with a project team that couldn’t seem to get all the right pieces together.  In fact, what was needed was to remove two members of the team.  One of them was in a key contributor position, but was just not disciplined enough to produce his part of the code (this was a firmware team).  The other was simply not contributing to the team because he didn’t understand his role and was not capable of fulfilling it.  While I had recommended the removal of these two on my 3rd day on the project, I had not insisted, and the result was a long slog.

What happens when you remove non-contributors from the team?  First of all, someone else on the team steps up to do what needs to be done.  Second of all, the whole team becomes more productive (and happy) because they are no longer saddled with the unproductive members.

Example 2: A client company launched a transition to Agile development methods in the development of a major sales-support package.  They hired an experienced team of software people and an Agile coach.  The program went well.  I was asked to assess the team and the project during its first year.  My assessment:  this team will do well no matter what methodology they use – because they are experienced people who know how to work in a team.

There was also an invisible success factor, invisible to the remote business people who chartered my assessment.  Within the ranks of IT management was an individual Director-level manager who secretly supported the Agile transition.  I say “secretly,” because the CIO turned out to be opposed to any special treatment of software developers (compared with, say, treatment of call-center operators), let alone “Agile” teams.  This manager quietly encouraged the Agile team and provided me with insight into all of the IT department politics that could affect the team’s performance.

If you manage to identify and engage the key success factors in real projects, you’ll be regarded as a genius.  But don’t let it go to your head, because a lot of it is luck.  Luck that is aided by keeping your eyes and your mind open.

If you’re managing a major project, it’s best to call upon resources (not just people, but information or equipment or software) that help compensate for any shortfall. So it’s a good idea to continually build up your network of contacts, your access to information, and your knowledge of available equipment and software.  Then, when you run into a roadblock, you can call on your network to help find what you need.  And of course, it doesn’t hurt to have a secret ally in the management ranks.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , ,

Stranger ways to fail

February 29, 2012

In the last article, I gave three reasons for IT project failure.  These are not the only ways to fail!  In this article I describe failure modes I’ve seen that are much less conventional – and harder to overcome without serious dedication at the top.

Here are the three reasons from last time:

  1. They’re not defined well
  2. The people doing the work are not a team
  3. They don’t have enough resources or the right resources

And here are the new ones:

4.    Management is fighting over who controls the project

There’s nothing nastier in corporate politics than a turf battle.  All the best-intentioned platitudes about teamwork and customer-centricity are forgotten when there is a fight for power.  If these are happening in an organization near you, then you’re probably hunkered down, waiting for the chips to fall.  The project work is also probably way behind schedule and no one is willing to take any risks while the battles are fought.

These projects usually falter when the funding becomes uncertain because of the battles.  That of course leads to failure reason #3 above.

5.    The project has been chartered in order to show off a capability, rather than to accomplish a real, customer-oriented goal

A U.S.-based company I was working in asked me to manage a development project that was being done on the other side of the Atlantic.  Why?  I found out later it was simply because the former VP of Software was now in Europe and he wanted to show off the capability of the European software development team.  Although we managed to deliver the product and the team performed well, the product was not well received.  It was really unnecessary.

6.    Middle management is truly incompetent

A client company started development on a system that was way outside the company’s traditional area of expertise.  When the managers realized they needed an essential software component and asked for it, the development team showed them the component that they had already developed, because it made no sense to proceed without it.

This company’s first and second level managers were in over their heads with regard to the technology.  What made it worse is that the two levels of managers protected each other from showing their weakness to anyone above the second level.  Both the system and the company folded within a few years.

7.    The CEO and the executive staff don’t support the project because they don’t understand its significance.

A company I worked for was the first disruptor of markets for the big players in computer systems.  It offered systems that were an order of magnitude less costly than the competitors, and this not only opened up markets and applications that were new, it began to eat into the margins and the market share of the big players.

Twenty years later, other new companies began offering systems that were an order of magnitude less costly than this company’s systems.  The company couldn’t respond adequately because the top management did not understand how these “cheap” systems could do what the more costly ones did.  They also failed to grasp the significance of software as a business, separate from the “iron” of computer hardware.  The company ended by being acquired by one of the upstart disruptors.

If you can find your way to a safe place to proceed with your project, keep on trying to establish good practices and excellent communication.  And if you’re depending on successful completion of the project?  Then get clear about what’s going wrong, and get help.

Filed Under: Agile Management Tagged With: , , , , ,

Three causes of IT project failure

February 13, 2012

IT projects often don’t get done.  Not just done late, but not done at all.  Industry statistics show that over 50% of major IT projects are not regarded as successful. They get abandoned because they’re too late or because they’re so far over budget that the sponsors give up.  Many more deliver something, but not what the sponsors really want, and not on time within budget.

Why do these projects fail to complete? Here are three major causes of IT project failure.

1. They’re not defined well

If the sponsors don’t define the project well, the people implementing it will apply their own ideas to define the outcomes.  This usually leads the project astray, because no matter how technically competent the implementers are, they are not mind-readers and they rarely have a clear idea of the business purpose of the project.

The best way to define an IT project is to start with the end – defining the measurable impact on business parameters that the project is intended to have.  From these, derive criteria for completion including demonstrations of the key capabilities and measurable test results.  If this seems hard to do, then you need to review why the project is being done.

2. The people doing the work are not a team

People implementing the project need to behave as a team.  If they don’t, the project is likely to fail.

You need good teamwork to get a project done.  What’s good teamwork?  It’s good communication with blaming; it’s clear acceptance of accountability for doing what each member said he or she would do;  it’s working cooperatively to solve the inevitable problems that come up.

If your implementation team is split across town or across continents, there needs to be active management of the communications so that the teamwork criteria are met.  Agile development, which relies a lot on self-directed teams, requires outstanding teamwork before any benefit from the Agile principles will pay off.

For example, a client company I worked with had parts of its web implementation team split between two facilities 750 miles apart.  When not enough results were coming through, the manager decided that Agile methods would solve the problem.  But the two parts of the “team” did not trust each other and each blamed the other part for the lack of results.  Only after bringing the top dozen people together in one room for two days per month did they begin to work out their common goals and start to solve the problems.

Leadership is also required in a self-directed team.  Leadership in this context means actively managing the team process and the management.

3. They don’t have enough resources or the right resources

The effort needed to complete an IT project is often underestimated.  A combination of implementer optimism and wishful thinking on the part of the sponsor conspires to make the budget for many projects inadequate.  This causes an unpleasant surprise when the project is nowhere near complete when the budget is spent.

You also need the right resources.  People who have the skill and competence to plan, design, code, test and deploy the program are necessary.  If any part of this sequence is weak, then a lot of time and effort can be lost during the project.

The implementers need the right tools, including software tools and a work environment in which they can use them properly.

Under-estimation of the scope of a project may lead it to grow too big for a single team to accomplish within the time required.  That can lead to further complications, because multiple-team projects require segmentation of the effort into coherent modules, and then the integration of the whole project has to be done by an integration team.  So when you discover the realistic effort needed to accomplish the project, you may also have to rework the whole management structures used to implement it.

If you want to insulate your company from IT project failures, you need to pay attention to project definition, team formation and adequate resources.  Then you have a chance to beat the odds and reap a successful conclusion to your IT project.

Filed Under: Agile Management, Painless IT Tagged With: , , , ,