Strategies for Software Development Project Success – Part One of a Two-Part Series
Best Practices for Improving Project Success: The Importance of Synchronization
Jan. 22, 2006 09:30 AM
A seasoned software development professional offers personal advice and describes best practices for improving project success, touching on communication, use cases, testing, and marketing.
While working on both in-house and external software development projects in the last couple of years, it occurred to me that certain challenges and best practices kept repeating across different projects. As I learned how to swim through the challenges and ride the waves of the best practices, I decided to make some notes, which I will summarize in this article.
In this part one of two series, I will examine two categories:
- Compensating for lack of face-to-face communication; and
- Writing better use cases.
This rather idiosyncratic advice is by no means comprehensive. My intent is not to teach you how to build software, but rather to discuss a few technical and non-technical issues that are critical to project success. Often, seemingly unimportant factors can make the difference between a good project and an excellent one. My advice focuses on the relatively small portion of overall project effort that these crucial factors typically represent.
1. Compensating for lack of face-to-face communication
Everyone knows that the single most important success factor for a project is good communication. This is a huge topic, but I will focus on one aspect that can really make a difference.
The benefits of face-to-face communication
Blessed are the teams that reside in a single location. Often, this is the case for small, startup businesses in which a couple of determined and ambitious people share the same goals and experience the same details of everyday life. Also, some larger organizations that effectively use agile methods base their internal process on face-to-face communication. When a team resides in a single building, people can meet face to face during lunch, in the corridor, and after hours, and these informal meetings are often more productive than regular scheduled meetings. I can remember numerous times when I copied notes from a crowded whiteboard after a long discussion and then used these shared ideas as the basis for a new plan.
However, business success and growth often makes it impossible to confine a high-quality team to a single location. Acquisitions, joint projects, and offshore development create demand for successful communication across different time zones and different cultures. In such cases, what are the best alternatives to face-to-face meetings?
Communication in a distributed environment
The first answer that came to mind was probably "email." I've found that email is a really useful communication channel, but it's also the first channel to be abused. What use are mile-long email threads when there is no time to read them? A good rule of thumb: If a thread contains more than three messages, you should probably switch to the telephone. This little rule has saved me numerous hours of writing pointless text in Lotus Notes.
In addition, there are other communication channels that -- although they cannot replace the intimacy of face-to-face meetings - can improve collaboration and understanding within a team:
- Project home page. Setting up a home Web page gives project leaders an excellent channel for one-way communication (or two-way communication, if they use wikis or forums/blogs). A Web page can explain what the project is, define main goals, and introduce team members. Managers can also use this page to post coding standards, "how to's" that will help team members set up the environment, and so forth.
- Online chat. This form of communication creates a virtual collaboration environment and fosters an easygoing exchange of ideas among team members. It is typically much more efficient to ping a colleague and ask for help via an instant messaging system than to play phone tag with that person. For example, IBM's system, Lotus Notes SameTime, integrates with the Lotus Notes directory, so you can easily find the right contact in your organization and see whether that person is logged onto SameTime. If you see a "Busy" indicator, you can assume that the person would not answer a phone call, either. SameTime also allows you to invite multiple people into a chat, so it's a wonderful way to conduct joint decision making on the spur of the moment, without going through the bother of setting up a formal meeting.
Some chat programs include other interesting features such as customized availability messages, the ability to save transcripts for future reference, and so forth. Keep in mind that different chat tools provide different levels of security, not all of them equally well-suited for professional use.
2. Writing better use cases
- Defect tracking system. This is another effective communication channel. Every software development project must cope with feature enhancement requests and bug reports at some point. An effective defect tracking system, such as IBM Rational ClearQuest, can help teams bring order to these requests and reports. In particular, the Unified Change Management (UCM) capabilities that you get by integrating Rational ClearQuest with IBM Rational ClearCase, allow you to associate activities with defect records and source code, which greatly improves the quality of communication on day-to-day issues. For example, if I need help with a component that isn't working right, I can look up tickets for that component in the defect-tracking database and find out whether the component is undergoing further work, as well as who is doing that work.
- "A cup of coffee." On the other side of every communication tool is a person. Isn't it great when someone calls you to just ask how you are doing, especially when you're working under pressure? Although your colleagues may be on the other side of the globe, it's important to remember how important these informal conversations can be for consolidating a team effort. Even if you are using the most sophisticated management and reporting tools, sometimes the only way to get the right information is by talking with another person. How do you invite your distant colleague for a cup of coffee? Maybe an unscheduled phone call shortly before the end of the day would do. Remember: You'll get such calls more often if you initiate them often yourself.
From a certain perspective, we can think of use cases as a form of communication. However, they are much more than that, so I treat them separately here.
Use cases have two enormous advantages over other system planning techniques. First, they give everyone involved in the project a correct understanding of the final user's needs and requirements. Second, you can assemble them long before the first prototypes of the developed code are ready. Knowing the application's key elements and the user's needs opens up the door for fruitful collaboration with the customer on one side, and between the different roles and teams involved in product assembly on the other side.
Simply put, a use case is a fairly simple document that describes either:
- Key scenarios that users must execute as part of their work (business use case).
- Interactions of the user (actor) with the system used for business (system use case).
Perhaps you are thinking, "So what? That's just another document." Actually, I thought the same thing before I first faced the challenge of having to put requirements and users expectations into a document that could be easily shared across different project roles. Very early in the project, the testing team and the documentation team started asking detailed questions on what we would be doing and how everything would work together. Until I discovered use cases, my answers were inconsistent, confusing, and very time consuming.
Of course, once I discovered how useful use cases could be for planning and answering these questions, I faced another challenge: learning how to write use cases effectively.
Know the user
Before jumping into interactions and scenarios, it is important to understand all of the targeted customer groups, differentiate these groups from one another, and specify their requirements and needs. Different user groups have different business use cases. For example, it is very likely that a tester tasked with validating compliance with a certain set of globalization standards will have different needs than a developer with a similar responsibility. The developer might have the knowledge, tools, and authority to fix some deviations right away, but the tester would likely have to file the defect and then wait for the developer to fix it.