The 7 Elements of Highly Successful Software Projects
By Thomas Salonek,
20 Jan 2009
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:
- Getting the right team
- Defining the problem
- Working effectively together
- Communicating frequently
- Working smart
- Constantly improving the process
- 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.
|