The 7 Elements of Highly Successful Software Projects

By Thomas Salonek, 20 Jan 2009

4.35 (18 votes)

Is your email address OK? You are signed up for our newsletters but your email address is either unconfirmed, or has not been reconfirmed in a long time. Please click here to have a confirmation email sent so we can confirm your email address and start sending you newsletters again. Alternatively, you can update your subscriptions.

Introduction

Successfully executing a software project requires a clearly defined plan that all parties understand and endorse. It also requires effective teamwork and people who are willing to put their shoulder against the work everyday. Once a team is ready to execute the work project, the focus needs to be on doing the right things and having systems in place to compensate for inevitable miscommunication and human errors.

Before laying out the game plan necessary for successful project execution, though, I'd like to share a broader thought about getting things done at work: Just do it! In my experience, it’s far better to take action than to procrastinate while obsessing about making things perfect. Perfection is nearly impossible to achieve, although it’s a worthy goal and one we strive for when developing software for our customers. Rather than software, I'm referring to general business decisions about priorities. I've seen too many organizations virtually grind to a halt over a single issue, or the inability of top managers to make a tough decision. Don't let this happen to you. It’s better to move and get things done than to let organizational rigor mortis set in.

Few professionals readily admit to being “process oriented,” which connotes images of anal-retentive individuals who are so busy cataloguing trees they completely miss the proverbial forest. I'd like to challenge that perception. People who can follow a carefully designed process are most likely to achieve success. This is a fact CEOs understand. When asked to name the main reason for the success of their companies, 75 percent of the CEOs leading Inc magazine’s top 500 companies said “superior execution in a mundane business.”

That’s pretty mind boggling, but it makes sense when you consider that more businesses face being reduced to a commodity due to global competition. When every corner shop can offer gourmet coffee, it’s the shop whose employees remember customers, greet them sincerely and serve orders in record time that stands out from its competition. Taking the time to focus on the little things can add up to big profits over time.

The rest of this chapter will focus on the best process for writing software and successfully launching a major software initiative. When viewed broadly, these steps are just as valid for any type of business initiative or major project. In fact, the process I advocate has a lot in common with best practices used in building anything.

Finally, as a side note, there’s been and continues to be different approaches on how to manage projects—waterfall, agile, lean, and the list goes on. While these different approaches each have their merits, as it relates to this chapter, I'm not advocating a specific method. And, while a lot more needs to be done to make projects successful, I haven't seen a project that lacks one of the “7” elements missing and was successful.

Projects are tough. For software, Gartner Group estimates that approximately 75 percent of software projects fail due to lack of technical consideration or poor business planning. Why is it so hard? What can be done? Here are the common elements of every project that we've shipped:

1. Getting the right team
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, you join the majority in the 75 percent.

1. Getting the Right Team

The topic of human capital (recruiting, motivating, retaining, etc.) fills bookshelves at the local Barnes and Noble. And it should. Studies show that top performers out produce low performers by a factor. In software it is a factor of eight-to-ten times. I won't try to cover this in depth but below are a few of the big rocks to get the best people:

• Get the best work. Great talent is drawn to great work. For Generation Y, get ready. Research suggests they are as committed to the work as the firm. When the work goes bad, they go (Generation Y is the age of five to the mid-20s).
• Take the time. I attended a class at Harvard. Several case studies had recruiting in the study. One of the firms, known for having the best-of-the-best talent, does 25-40 interviews. Yes, you read that right. When adding to your team, honor your interview process (don't skip steps) and invest the time on the front end to ensure a tight fit between the new employees’ and your company’s values and performance.
• People leave people. People don't leave companies—people leave people. Pick your leaders wisely and employee retention is simple.

2. Defining the Problem

Ever heard the adage “a problem defined is half solved”? This is especially true in software. An IBM study by Felix & Watson found that well-defined objectives were the number one factor in successful projects. Expect the following in your plan:

• Project plan. This high-level document defines the project vision and Critical Success Factors—i.e., what the project must deliver to be considered a success, and areas of responsibility.
• A requirements document. This defines “project complete.”
• A prototype, mock-up, or demo. Most people are visual. A visual tool is a clear way to communicate and take care of misunderstandings.
• A Gantt chart or Sprint Plan. A Gantt chart states who, what, when and defines interdependencies. In other methodologies, like Agile, a formal Gantt chart may be replaced by a simpler “Sprint”—a list of the highest priority development items to tackle in the next 30 days.
• A risk plan. It should define what’s likely to go wrong and what happens when it does.

Depending on the project, there may be additional documents required. For example, in software there are additional documents like a functional design specification, a logical and physical model of the problem, and test scripts to define what complete and functional means. Beginning without a clear plan 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 four to six. This size is large enough to have effective dialogue and collaborative thought, but small enough to be efficient. If the project is large, break it up into pieces tackled by teams of four-to-six people.

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 vendor and communicate this with your staff.
• Clearly state expectations. The documents shared in 2. Defining the Problem, puts everyone on the same page.
• Choose a central point of contact. This should happen on both ends.
• Clearly state priorities. When flushing out the functional requirements, prioritize features. When the releases are being defined, it is key to know what is a “go” vs. “no go” feature.
• Constantly communicate (see next section for more on this important topic).

4. Communicating Early and Often

In fast-moving environments—most companies today—daily huddles can keep communication consistent and effective. Intertech uses huddles. In huddles, which take no more than 15 minutes:

• Each team member gives an update. This streamlines communication and reduces one person having to retell their story throughout the day.
• The daily number is shared. This is a number that measures the bottleneck or health of the project. The number changes throughout the project. For example, in software beta testing, this could be number of outstanding bugs. If you have six data consecutive points in any direction, you have a trend.
• Each team member shares a stuck item. Sharing a stuck item brings up issues early, often and enables the slaying of monsters (problems) while they're little.

Huddles can cascade to keep everyone on the same page. For example, if there are three project teams working on the overall project, the separate project teams have a huddle followed by a huddle of the three project leads and their superior.

It can be tempting to forgo communication tools, like huddles, when you're in the end game and near project finish. This is when you need them most. If you're working on a longer project, build in systems that create a frictionless environment. At Intertech, twice per year, we ask our people:

• Name one thing we should stop doing, start doing, and continue doing.
• Name a hassle for you, a hassle for our team, and a hassle for our customer (internal or external). A hassle is a second wasted doing something that could be avoided by making a change to how work is done.

The above help removes the “noise” that stops people from doing their work effectively.

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 greatest impact on the future of the project?” 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. If you have the decision makers together in a huddle and a decision needs to be made, do it.
• Remember 12-hour workdays aren't 12-hour workdays. If projects are being completed because the modus operandi is ongoing 12-hour workdays, the real work accomplished in the day will cease to happen during the entire 12 hours. People still need to eat, see their families, have friends, get their clothes cleaned, etc., and they'll find ways to do just that even if you expect a 12-hour work day. In other words, don't encourage an environment where “crunch time” is “business as usual”—it loses its meaning and effectiveness.
• Remember there is no silver bullet. Success is the result of series of things consistently done well. If in the heat of the project, there’s an idea, solution, team member, or vendor that has “the fix” and it sounds too good to be true (you know what’s coming) it probably is!

6. Constantly Improving the Process

Because this isn't the last project you'll be delivering:

• Be prepared to change. For example, in software, good software doesn't die, it just changes a lot (think of Microsoft Word). Factor in ongoing maintenance and changes from the start.
• Follow some process. Before we can improve something, we need to understand what it is. Follow a process proscribed by your vendor, then make it your own and constantly improve upon it.
• Encourage reviews. No one has the corner on good ideas. Even if you are moving fast, get buy in and check off.
• At project end, make sure that you've got the completed set of documentation.
• 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 project finishes, 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 work in a known state. With multiple people making changes to a project, ensure that the details are pulling together. For example, in software, this means building the entire application daily.
• Everyone should ask, “Is what I'm doing going to help us complete the project?” This may mean skipping helping out with interviews, sitting through all company meetings, etc.
• Ask, “Does the problem need to be fixed?” For example, in software when a project is nearing completion and there are small things that are not quite right, sometimes fixing the bug can introduce more bugs. Is the problem something you can live with and fix at a later time or is it critical?
• At the end of the project, when people are verifying the work is complete (in software this is QA), this is not the time to solicit and add more to the project. It’s the time to nail the requirements and get it done.
• If a project deliverable 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 then hit it no matter what.

Celebrate and recognize team members when the project is finished. Whether it’s formal or a beer out with the team, it matters. While there are more things we need to do to be successful in managing projects, these guidelines cover the minimum basics needed to finish on time and on schedule.