Painless IT

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.”

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

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

Software, software everywhere

January 23, 2012

Software is different from other technical stuff.  It’s abstract, invisible, and runs at extremely high speed.  So the people who are good at working with software tend to be different from “ordinary” engineers.  They have to be good at visualizing the abstract processes and the mathematical algorithms that make up the procedures implemented in software.

Software people are different, so their managers need to be able to deal with the difference.  Effective software managers know what’s critical to a well-functioning software team and those managers get good at providing it, even in the face of obstacles.

Obstacles come from upper management that doesn’t understand how software, and software people, is unique.  As a result, they assume that a manager who has skills in Operations can just as well manage software.

I’ve seen IT shops where the best software people left the company quickly after being treated as if they were call-center operators.  For example, the management assumed that the software people could be located anywhere in the building, that they didn’t need any special whiteboards to keep track of their project information.

Why should you care? After all, can’t you just hire the brains you need for software?  Well, not so fast.  You’re competing with every company in the world for the same kind of brains. Unless you’re in an entrepreneurial, fast growing, innovative company, software people will not prefer working for you over going to work in a more exciting environment.

IT is undergoing rapid change, primarily driven by the availability of cloud services.  But the cloud just moves the data centers to somewhere else. If you look closely at internal IT activities, you will realize that IT is itself a software-intensive activity.

This sounds self-evident, but it’s not a joke.  It’s a reality that many financial and operations executives fail to understand.  Everyone, from the business analysts to the website deployment people are not just software users – they have to understand software principles to do their work.

Business competition will come from new players, and from old players who master software tools and the business possibilities opened up by software.

As software becomes an integral part of business, there is a subtle shift in what management has to do and to know.  You now need staff – or consultants – who are knowledgeable about software and its workings.  And from them you need to learn what software means for the future of your business.

Is there something you’ve learned recently about software?  I welcome your comments.

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

How can IT management fail to understand business goals?

January 10, 2012

“Now more than ever, IT must invest the time to understand specific business goals and translate IT metrics to reflect an impact against these business goals.  Often there is a gap between what IT reports and what is of interest to the business.”   — An Introductory Overview of ITIL V3, itSMF, 2007, p. 38

There’s been a lot written about how IT and business are misaligned.  See for example, Susan Cramm’s excellent book.[1]  But how do they get that way?  One cause is that many IT people don’t understand business.  Another is financial invisibility of IT due to budgeting processes.  But these are not the big killer causes.

I believe there are three major causes:  physical distance, psychological distance, and IT overload.

Physical distance of IT from the business leads to isolation in many ways.  One of my client companies had their IT people in a city 750 miles away from the home office.  Not only did this impose communication barriers, it meant that the IT people were living in a different culture from the home office people – even though both locations are in the United States.  Of course, when you add in the distance to some of the offshore contractors who are handling some IT services, physical distance means even more cultural distance.

Psychological distance can be caused by having objectives that don’t relate to business goals and by being managed in a “silo.”  For example, IT may report in to the CFO, and management metrics may relate only to financial performance.  As long as IT is budgeted as an operational expense, then no amount of encouragement will get IT managers to view what they’re doing as a strategic investment.  This can be aggravated by failing to include IT people in business planning.  Finally, I’ve seen IT organizations where the business tools used by the rest of the business are not in use in IT.

IT management overload is the third major cause of misalignment.  Beyond the usual overload caused by rapidly changing technology and shifting responsibilities (associated with Cloud services, for example), IT management is typically trying to do more with less budget.  As the pressure to perform increases, IT management concentrates on operational measures rather than business metrics.  In addition, technology shifts are raising the cost and complexity of legacy system support.  So IT managers tend to focus on reducing these burdens, rather than looking for new initiatives to support.

Where can we start to correct the lack of alignment between IT and business?  After addressing physical location and reporting structures, the most productive way to get alignment is with common metrics.  Look for business metrics that are relevant to concrete business results and are particularly dependent on IT service delivery.  Then make sure that IT managers understand the business metrics.  Finally, make sure that they buy in to being measured by these metrics.  To do that, of course, it is best to include them in business planning processes – and not just as number-providers.

What are your experiences with IT – Business alignment?  I welcome your comments.

[1] 8 Things We Hate About IT by Susan Cramm, Harvard Business Press, 2010 http://www.eighthates.com/

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

Complexity is good – or is it bad?

December 6, 2011

I grew up in a family of engineers.  My father studied electrical engineering in college, but never practiced it because he graduated from college during the Great Depression.  Two of my uncles are engineers, and my older brother preceded me in going to Cornell as an engineering student.

I have always felt that engineering is not only an honorable profession, it also leads to a practical lifestyle that values inquiry, problem-solving and efficient solutions to the challenges in life.  So you may not be surprised to learn that I am a fully qualified lifelong nerd.  I love examining things to discover how they work.  And the more complex the mechanisms, the more interesting they are.

This is where it gets to be a problem.  When I invent something new, like a part of a computer, I revel in the complexity of the thing I’m building.  As long as the complexity serves a purpose, such as actually making the thing do what it’s supposed to do, my brain is tweaked in pleasurable ways when I contemplate the complexity.

If you’ve been reading any of the recent pieces about Steve Jobs, you’ll have understood that part of his brilliance was being able to conceive of simple and easy-to-use products that “just work.”  I worked with Steve in the early days of Apple, and I can verify that it was a challenge being an engineer in a place where the visionary boss kept revising the product based on his latest concept of simple.  Yet even engineers have a principle they repeat to each other to counterbalance their tendency towards complexity – the KISS principle: “Keep it simple, stupid”.

A quote attributed to Einstein says “Make it as simple as possible, but no simpler.”  This teaching admonishes us to simplify our theories, but not so far that they no longer apply to the real world.  Jobs’ vision was to make products that contained complex technology but worked well and intuitively for the common person.  And from that basis, he led the creation of products that have changed the way the world works.

So does this mean that I’m giving up on complex ideas and mechanisms?  Not at all.  The mental contortions I need to undertake to understand complicated things still give me pleasure.  And I believe they keep my mind alive in important ways.  The key to living with such an engineering mind is to keep it from running my life.  I still listen to J.S. Bach’s music with satisfaction at the complexity of the counterpoint and harmonies.  But I also meditate on emptiness to keep the logical brain in check.

The next time you hold a complicated piece of consumer electronics in your hand – such as your mobile phone – take a moment to reflect on its complexity and its simplicity.  Encapsulating one of these in the other is an art.  And to accomplish that encapsulation, you need both engineers and artists.  Long may the engineers and artists work together.

John Levy works with Finance and Operations executives who are sponsors for new IT-based business capabilities.  He helps them to succeed with their projects and to transform their relationship with IT.

Getting business value from every dollar spent in IT is not easy.  You need a guide who is knowledgeable about technology and also speaks the language of business.  John specializes in rapidly getting IT to align with business strategy and to contribute efficiently to the success of the enterprise.

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

For more information, please visit https://johnlevyconsulting.com , email him at info@johnlevyconsulting.com , or call 415 663-1818.

 

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