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: , , , , ,

Agile Clouds

December 21, 2011

Buzzwords abound in the Business IT world. You can’t ignore these words because they come at you from all sides. To help you cope with the possible hype you’ve been hearing, I offer you a brief overview of the realities of two of them– “Cloud” and “Agile”.

The Cloud

Everyone touts “the Cloud” as the latest thing, yet many aspects of the Cloud have been around for years. If you’re using Salesforce.com, for example, you’ve had software as a service (SaaS) for as long as you’ve been a subscriber. In my office, we use a CRM (customer-relationship manager) service named Highrise by a company called 37Signals. There are many satisfied users of these cloud services, but it’s best if you understand the tradeoffs and pitfalls. Here’s a quick summary:

What’s most unusual about the Cloud? – it accommodates temporary load variations

Using software that’s running “in the Cloud” gives you the capability to radically change your usage of the computers. So if you have a temporary load that is 100 times your average load, you can “provision” a bunch of servers and cover your needs in just a few minutes’ interaction with the cloud service.

What’s the biggest caveat about using the Cloud? – you have to be using standardized services

Cloud service providers can give you what you want in a moment’s notice. But unless you’re using a service that is standard – that is, not much different from everybody’s else’s service – you will not find it economical. So don’t look to cloud services to differentiate you from your competitors, because they are probably using the same or a similar service, too.

What’s the payoff of using the Cloud? – OpEx, not CapEx

You pay only for what you use, and it’s usually a lot less than the cost of provisioning your own data center and buying the software. So using the cloud lets you get IT work done efficiently on operating expenses alone.

What else could be a problem in using the Cloud?

  1. Security – don’t plan to put your most confidential data into the cloud. For the data you do put in the cloud, make sure you have adequate backup and restore capability, or suitable data duplication.
  2. Availability – be sure to check on service level agreements (SLAs) from your cloud providers. Think about how many minutes of downtime a year you can afford, then compare the offerings.
  3. Competitive services – there aren’t many cloud service standards yet, so moving from one cloud provider to another can be a problem.
  4. Rogue IT – If you’re managing IT for a large organization, you may discover that department managers are buying their own cloud services. This may be efficient and effective for them, but it could undermine your efforts to get IT to be consistent and effective across the organization. Get out in front of your users’ needs, and offer consulting on cloud services to your departments.

For a longer essay on the ups and downs of cloud services, I recommend you read Robert Keahey’s article titled, “The CFO’s Guide to the Cloud”.

Agile

Agile software development originated with the “Agile Manifesto” in 2001. I like to describe it as a bunch of software developers who got together and said to themselves, “We’ve been so badly managed for so long, surely we can do better ourselves.” So they laid down 4 values and 12 principles for software development. Since then, Agile has proven to be 2 to 3 times more efficient than previous “waterfall” methods for many types of software development. And the Agile principles have begun to be taken into other areas of management. Here are a few key things you should know about Agile:

What’s most unusual about Agile? – progress is more visible

Agile methods work by dividing up a large project into increments that can be done in short intervals. The interval chosen is usually 2 or 3 weeks. At the end of each interval, the project team demonstrates working software. Since you can see the software working sooner and more often, you get more confidence that the claimed progress is real, because you can see it.

What’s the biggest caveat about using Agile? – it requires more involvement by business people.

A development team in an Agile project requires daily access to a business person who is responsible for the results. This guarantees that software developers can talk over what the requirements really mean. It also requires the business person to be on-call every day, as well as present in person at the end-of-iteration reviews every 2 weeks. Don’t expect an Agile team to be effective if you don’t provide for this level of time commitment by one of the business leaders.

What’s the payoff of using Agile? – you can keep up with changes in the market and in your business priorities.

At each interval the priorities are set for what should be done in the next iteration, so you can adapt the project to changing conditions as you go. This helps to keep you from paying for a lot of work on the wrong thing. In fact, this could allow you to kill a project after only 10% of it is done, rather than having to wait until 60% to 80% of it is done to find out it’s the wrong thing.

What are other benefits of using Agile? – Agile could infect your company’s project management system and make everything you do more efficient. At the very least, using Agile for software development in IT will make your business people and your IT people work closer together on major developments. And that couldn’t be bad, right?

 

Filed Under: Agile Management Tagged With: ,

Business, Academia, Government – do we have the same problems?

August 10, 2010

Every one of us is dealing in one way or another with high technology. Whether it is by trying to develop a product, trying to deliver a service, or just preparing our slides for a presentation, we all deal with the high-tech world.  This usually means that we must communicate with high-tech people, and typically the results we get are dependent to some extent on how well the high-tech people do their work.

Communicating with high-tech people is a challenge. Not only do they speak their own brand of jargon, they also tend to be very literal.  Like the literalness of the computer itself, high-tech people seem to think that if you ask for a three-pronged left-handed widget (or a thingumbob, if you like), then if they deliver a three-pronged left-handed widget to you, you should be happy.

Unfortunately, it doesn’t work that way. With software, for example, the requirements are never completely known.  Typically, when the first working model of a new software system is shown to the people who asked for it, their reaction is: “Oh.  I see what you have here, but what I really want is something different.”

This can be frustrating for the technologists who worked for a long time on the development.  One of their countermeasures now is using Agile development practices, in which a working prototype is shown to the “customer” early and often.  This allows the developers to correct their course early and gain confidence that they are building something that will actually be useful.

But why is it so hard to specify what we want in advance? Is it because we don’t speak the same language as the techies?  Or is there something inherent in high-tech that obscures the simple outcomes that we know we want and we think we have asked for?

I believe it is both. Not knowing how high-tech stuff is constructed, we don’t know which jobs are hard to do and which are easy.  We also don’t know how elaborate the underlying structure has to be in order to get what looks like a simple result.  So we ask for things that we want and find ourselves puzzled by the groans from the technologists who see years of work ahead of them to satisfy the request.

We also don’t really know what we want when it comes to interactions with a computer-based system, because the possibilities are endless and the examples we’ve seen in the past color our view of what we think the interactions should be.  For example, if you’ve used Word Perfect for years to do your word processing work, you will not find it easy to switch to Microsoft Word, because the interactions and functions are different.

There’s a new discipline in computer systems development called user interaction (UX) design.  It calls on specialized skills ranging from graphical design, human perception and interaction protocol design, to database design and web programming.  But even as this new discipline is helping to make systems easier to interact with, no one can substitute for you, the user or customer, in defining what the system should do.

Sometimes you have to say, “I want it to be easier to use than this,” when you see how a system works, even when you don’t know how to make it easier.  If you challenge the development team to try different ways to make it easier, you will usually get something better.

But this poses a problem. If they are experimenting with various ways to make the system easier to use, how long will it take to get to the finish line?  How much will it cost?  The fact is that doing engineering and design requires creativity and experimentation.  And you can’t schedule a breakthrough.

So you have to settle for setting a limit on how long or how costly the project is to be.  An entrepreneur may run out of money before delivering a satisfactory system. But if you are constrained to actually get a working system, you want the best you can get within the constraints.

This comes back to the Agile approach. If you ask to be shown a working prototype often, you can do course-corrections frequently while you also gain confidence that the developers are meeting the most important criteria for your project, because you make them show you how the system meets those criteria first.

The Agile Management Bottom Line

Give up trying to specify everything at the start.  Begin by prioritizing the key features or results you need, and ask for frequent demonstrations of a working system.  You’ll end up with a lot more confidence in your high-tech developers, and they will be less frustrated with you.

—–

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering.  He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years.  John’s book on management for technology executives, Get Out of the Way, was published in May 2010.

For more information, please visit his website at https://johnlevyconsulting.com ,

Email him at info@johnlevyconsulting.com , or call 415 663-1818.

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

Metrics of Success in Development – Part 3

January 26, 2008

Today we’ll finish the list of ten questions that can give you a quick measure of your development group or department. The purpose is two-fold: to let you see how you measure up compared to other similar departments, and to suggest ways in which you can think about the stresses in your department.

Let’s launch into the final four questions, then we can total them up.

7. Viewed from other departments (outside of Development), how would managers rate your development managers and engineers in each of the following areas?
(a) Cooperativeness (with outside people)
Extremely cooperative – add 3 points
Very cooperative – add 2 points
Cooperative – add 1 point
Uncooperative or unavailable – add 0 points
(b) Flexibility (willing to work with and compromise with others outside the department)
Extremely flexible – add 3 points
Very flexible – add 2 points
Flexible – add 1 point
Inflexible – add 0 points
(c) Team-orientation (beyond the Development department teams)
Extremely team-oriented – add 3 points
Very team-oriented – add 2 points
Team-oriented – add 1 point
Not team-oriented – add 0 points

8. What percentage of the company’s gross revenues in the most recent year were allocated to Development (or R&D)? (If your company has no revenues, or if revenues are less than the Development budget, answer “over 10%”)
(a) over 8% – add 3 points
(b) 4 to 8% – add 2 points
(c) 2 to 4% – add 1 point
(d) less than 2% – add 0 points

9. Comparing this year’s Development budget to last year’s, how did it change?
(a) Increased by 20% or more – add 3 points
(b) Increased by 5 – 20% – add 2 points
(c) Stayed the same or changed by less than 5% – add 1 point
(d) Decreased by more than 5% – add 0 points

10. The number of concurrent development projects now in my department is
(a project is defined as an activity with a timeline and a goal which needs at least 1 full-time person to make progress towards the goal; if you have many small projects, you can count the number of project leaders instead)
(a) over 25 – add 0 points
(b) 15 to 25 – add 1 point
(c) 5 to 15 – add 2 points
(d) 1 to 4 – add 1 point
(e) none – add 0 points


If your total points add up to 52, you have a perfectly-performing development organization and have no need for improvement. For the rest of us, the points are probably in the following ranges:
Excellent: 37 to 52 points
Good: 22 to 36 points
Fair: 13 to 21 points
Poor: 12 points or fewer

How did you do? What does this mean? If you think about the stresses on your department, you can see that the point score is not as significant as the individual issues you’re facing. Are you having a lot of turnover? Slipped schedules? Complaints from other departments about your people? These can all be aggravated by declining budgets which are outside of your control.
Later we’ll examine some of these issues and how you can find ways to work around them. In the mean time, click on the Comment button and let us know how you scored.

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

Metrics of success in development – Part 2

January 26, 2008

Last time we listed the first three questions of a self-assessment questionnaire for Development managers. Those first three related to project completion, staff turnover, and how well the initial functional or feature list was met. If you are having problems delivering products, most likely you will experience problems in one or more of these initial three areas.

There is a less tangible measure that relates to suitability of the product to the customer. But I’m still trying to figure out how to ask about that in a way that leads to a consistent and useful measure. If you have any suggestions, please make a comment on this blog.

Here are the next three questions:

4. How many hours per week are put in by your project or program staff? This is to be answered in two parts: first for the average over the life of the project, and then for the peak of the project or program. Answer this for each of the most recent 3 projects or programs.

4a. Average over the project or program:
Over 60 hours/week (add 0 points per project)
50 to 60 hours / week (add 1 point per project)
40 to 50 hours / week (add 2 points per project)
less than 40 hours / week (add 0 points per project)

4b. Peak week during the project or program:
Over 80 hours / week (add 0 points per project)
70 to 80 hours / week (add 1 point per project)
60 to 70 hours / week (add 2 points per project)
40 to 60 hours / week (add 3 points per project)

5. How many direct reports do you have? (Direct reports include staff assistants, administrators, secretaries, project leaders, managers and interns)
Over 12 (add 0 points)
10 to 12 (add 1 point)
8 to 9 (add 2 points)
3 to 7 (add 3 points)
0 to 2 (add 0 points)

6. Of your direct reports, how many do you regards as “problem” employees (people you will replace when there is an opportunity)?
0 (add 3 points)
1 (add 1 points)
2 (add 0 points)

Questions 4 and 5 are searching for sustainability in your project loading. It’s OK to have peak weeks in which people are working 10 to 20 more hours than is typical during the project. But if you are driving everyone to work more than 60 hours per week on a long-term basis, you are not getting output that is sustainable. It may be time for you to institute metrics that measure results rather than inputs. Then you can experiment with different work schedules to see which ones result in the greatest output.

Sustainability applies to you and your management time, too. If you have more than 9 direct reports, the odds are that you are (a) not managing all of them as well as they could be managed, or (b) overloading yourself with management tasks that give you little time for planning and strategic analysis.

Next time we’ll complete the question list and tally the points for a complete score.

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