The CTO Handbook/Job Manual: A Wealth of Reference Material and Thought Leadership on What Every Manager Needs to Know to Lead Their Technology Team

e-Do's and e-Don'ts

The 7 Elements of Highly Successful Technology Initiatives

"More people have ascended bodily into heaven than have shipped great software on time."

- Jim McCarthy, Dynamics of Software Development

When I first read the above quote, I thought it was humorous. After years of being committed to delivering software on time and on budget, our customers have reassured us that shipping on time with intended features is the exception.

GartnerGroup estimates that approximately 75 percent of e-business efforts fail due to lack of technical consideration or poor business planning. Why is it so hard? What can be done? I've seen a set of elements in every project we've shipped:

1. Selecting the right partner

2. Defining the problem

3. Working effectively together

4. Communicating frequently

5. Working smart

6. Constantly improving the process

7. Understanding the end game

Miss one or two of the above, and you join the 75 percent majority.

1. Selecting the Right Partner

Ninety-seven percent of organizations have outsourced or used consulting services for some part of their e-business initiatives at some time, according to VARBusiness/Reality Research. Obviously, choosing the right partner is key. Without question, the market space of providers is crowded - most having come into existence over the past several years. When looking for a partner:

• Take time to pick a good provider. Ed Yourdon, an author and software methodologist, stated the difference between a good and bad programmer is tenfold.

• When interviewing prospective vendors, see the work and meet with the people who will be involved with your project. Don't fall for bait-and-switch - meeting with a ringer on the sale and working with a junior staff member on your project.

• Look at the long-term track record of the firm. Many new firms have sprung up, and old firms, previously entrenched in Y2K work, are touting e-business expertise. Firms coming from a client/server-centric background are more likely to have the skill sets required for shipping Web-deployed software.

• Make sure you're comparing apples to apples. Unlike cars or detergent, there isn't always a clear way to make sure you are getting the same thing - make sure the work up front includes time for changes to the prototype, design, testing, and staged quality assurance steps, as well as follow-up support.

2. Defining the Problem

There's an adage that a problem defined is half solved. This applies to software. An IBM study by Felix and Watson found well-defined objectives were the number one factor in successful projects. When we work with a customer we have several methods we use to define objectives:

• Project plan: This high-level document defines the project vision, critical success factors - what the project must deliver to be considered a success - and areas of responsibility.

• Functional design specification: This document is built in conjunction with a prototype and defines what the system does.

• A prototype: While not containing any actual business functionality, this creates an interactive way to design the system. Using the prototype, all flows of the system are defined.

• Technical design document: This document has multiple parts. It defines logic, data, and infrastructure and how they fit together.

• Gantt chart: This timeline states who, what, and when, and defines interdependencies. As the project progresses the Gantt chart is updated. The Gantt chart can also show "what if" scenarios - "what if we remove a person" or "what if we add a feature."

Beginning without the above is like building a house without a blueprint.

3. Working Effectively Together

Expect small teams, phased releases, and frequent deliverables. An ideal project team is fewer than six. If the project is large, it should be broken up into features and tackled by feature teams: project teams of fewer than six.

Working with an outside vendor introduces challenges. All are manageable. To work effectively:

• Define clear lines of responsibility. To stop turf wars before they start, clearly define the role of your vendor and communicate it to your staff.

• Clearly state expectations. The documents shared in Defining the Problem (#2 above), puts everyone on the same page.

• Choose a central point of contact. This should happen on both ends.

• Clearly state priorities. When fleshing out the functional requirements, prioritize features. When the releases are being defined, it is key to know what is a "go" versus a "no go" feature.

• Constantly communicate.

4. Communicating Frequently

In working with an outside vendor, because they may not be physically at your location, you can wonder what they are up to or what roadblocks they might be encountering. Expect regular updates. At a minimum, expect weekly updates.

In fast-moving environments - most companies today - daily huddles can keep communication consistent and effective. At go-e-biz.com, we use huddles. In huddles, which take no more than 15 minutes:

• Each team member gives an update. This streamlines communication and reduces the likelihood that one person will have to retell his or her story throughout the day.

• The daily number is shared. This is a number that measures the bottleneck. The number changes throughout the project. For example, in beta testing, this could be the number of outstanding bugs. Six data points make a trend.

• Each team member shares a stuck item. Sharing a stuck item brings up issues early and often, and allows fixing before they become unmanageable.

It can be tempting to forgo communication tools like huddles when you're in the end game and ready to ship. This is when you need them most.

5. Working Smart

IBM built an empire on the word "think." Thinking is key to deploying applications on time. To get people thinking:

• Encourage team members to constantly ask, "What could be done today that would have the greatest impact on future development?" For example, I've seen expensive developers without computers because a manager was "too busy" to order them a few weeks back.

• Keep meetings, including daily huddles, focused. Set meetings for first or last thing in the day or right before lunch. Cut off talkers. Honor time.

• Don't let meetings make more work. Make decisions on the spot.

• Remember that 12-hour workdays aren't 12-hour workdays. If projects are being shipped because the modus operandi is ongoing 12-hour workdays, the work in the day will cease to be 12 hours. People will still need to eat, have friends, get their clothes cleaned…Don't have crunch time be all the time - it loses its meaning.

• There is no silver bullet. From business process reengineering to object-oriented programming to code generators, there isn't one thing that will make development easy or simple. Rather, like anything, it is a set of things consistently done well by the management and technical people to produce a great result.

6. Constantly Improving the Process

As e-business becomes business, a significant number of business initiatives have an IT spin. Because this isn't the last one you'll be delivering, or the last version, you need to:

• Be prepared to change. Good software doesn't die; it just changes a lot - the next version of MS Word will be release 10.0. Good e-business software requires business objects, well-defined customer profiles, clear business events - these are focused efforts, not by-products. Sometimes this will cause differences in the original cost, making one vendor appear a lot cheaper. Factor in ongoing maintenance and changes.

• Follow some process. Before we can improve something, we need to understand what it is. Follow a process prescribed by your vendor; then make it your own and constantly improve on it.

• Encourage reviews in the business and technical communities. No one has the corner on good ideas. Even if you are moving fast, get buy-in and check-off.

• Make sure you have documentation, all of the code, and it meets your standards. Programmers and vendors leave. When your project is wrapping up, make sure you have all you need to make changes to your e-initiative.

• Do a post mortem. Don't blame. Ask, "What could be done to make it better?"

7. Understanding the End Game

The End Game, the time right before the software ships, can be difficult. It's manageable if you follow a few simple steps:

• Keep teams on track. Tell them to turn off e-mail and voice mail, and stay focused. Beyond the huddles, hold off on other meetings that may be "fluff."

• Keep the site in a known state. With multiple people making multiple changes, expect full builds of the site daily.

• Everyone should ask, "Will what I'm doing help us ship?" This may mean skipping helping out with interviews, sitting through all company meetings, etc.

• Does the bug need to be fixed? Sometimes bug-fixing introduces more bugs. Can you live with the bug, or is it critical?

• Alpha, Beta, and "Soft Launch" releases are not the time to solicit features. It's the time to shake out bugs and ship.

• If a date needs to be changed, don't change one bad date for another. If a revised date is set, get the team involved in setting the date, and hit it, no matter what.

Celebrate and recognize when the project is finished - whether it's formal or a beer out with the team. Napoleon said, "I've found an interesting fact - men are willing to die for medals." Recognition results in heroic acts.

While the list of things that are required day-in-day-out is much larger than seven, I've never seen a project missing one of these seven elements ship on time, on schedule.