Soft Skills


In addition to concrete artifacts that need to be produced in this phase, important "soft" project elements must be attended to as carefully as artifacts such as documents and prototypes. You need to set a clear vision for the project and establish clear and continuous lines of communication.

Setting the Project Vision

What exactly does "setting the project vision" mean? It is far more than simply reading a mission statement to the project team. It is a process. It is the process of helping the project team understand the reasons and motivations for the team to exist. It is the process of coming to understand why the customer wants to spend money to develop the project in the first place.

Tales from the Trenches

Years ago, I spoke to a colleague in the organization we worked for. He was working on a project in another division of the company. We had previously worked together on a project that had reached a successful conclusion, and we had moved on to other projects within the company. I asked him about his new project. He told me he was working on software related to control systems aboard a nuclear submarine. "Wow!" I said with a bit of envy. "That must be quite exciting!" "Not really," he replied. "I was excited when I was first told about the project. But if they hadn't told me what this project was about, I wouldn't have a clue it had anything to do with submarines. For all I know, we could be working on software for a new model of a washing machine."

I never forgot that conversation. Without vision, and the resulting sense of urgency, the project quickly becomes just another job to team members. As a result, the normal trials and tribulations that are a part of all projects become insurmountable obstacles and the focus of team members. Throughout my experiences, I have seen similar examples of failure to instill the vision, and a sense of urgency, in project team members. Team members become disillusioned, and morale suffers. How can this be prevented? How do you instill excitement in the team? The following sections provide some ideas.

Seeing the World Through the Customer's Eyes

On most projects, some project personnel, especially the programmers and developers, seldom if ever meet directly with the customer. Consequently, they get to know the customer only through requirements documents, Vision Statements, and perhaps feedback at major milestones that occur throughout the project lifecycle. This is a missed opportunity. The person best equipped to help you meet this challenge is the person (or persons) responsible for the team's existence your customer! Furthermore, developers are generally very creative individuals. A better understanding of the environment in which the users of the software operate on a day-to-day basis can lead to ideas for more innovative features and solutions. This is not the same as simply knowing the requirements.

Step 1: Meeting with the Customer

The first step toward the solution is to meet with your customer. If you are part of an offshore team, this meeting (and subsequent meetings) may need to take place electronically. (See Chapter 9, "Navigating the Requirements Management Process," for more discussion on this.) If possible, this initial meeting and subsequent meetings with the project team should take place at the customer's site. Explain to the customer that you want them to brief your team on the following topics:

  • What problems and challenges led to the decision to create this project?

  • What alternatives to the establishment of this project were explored, and why were these alternatives dismissed in favor of establishing the project instead?

  • What problems relating to the project keep them up at night?

  • How is this project critical to their business?

  • How will a successful conclusion to this project help them?

Step 2: Meeting with the End Users

On smaller projects, the customer and end users are one and the same. If your customer and the end users of the project you are about to build are different groups of people, ask if the project team can have an on-site visit with the end users in their work environment. Obviously, this is not always possible. If the end users are onboard a submarine, as just discussed, you may not be able to visit them in their environment! The same holds true if the project team is offshore. In either case, the next-best solution is to meet with one or more of the key end users, preferably in person, or electronically if necessary. It is important to note that these are not requirements-gathering sessions. The purpose is to orient the project team to the customer's environment. This gives context to the requirements-gathering sessions that will ultimately follow. Be sure these users understand the meeting's purpose ahead of time. Without this explanation, most end users will assume that the group wants to hear about their wish list for the software's functional requirements. You do not want to discuss specific requirements in this meeting. Here are some suggestions to explain to the end users what needs to be covered in the meetings:

  • Tell the users you want to hear about their jobs as they relate to the project.

  • How do the users envision the product helping them do their jobs?

  • How do the users currently do their jobs given that the product to be produced by the project is not yet available?

  • Will the system to be developed replace an existing system? If so, what do people like and dislike about this legacy system?

  • Does the system to be developed automate a certain task or set of tasks for the users? If so, what are some examples of other tasks related to the new system that the new system will not provide? Why weren't these tasks included in the project's scope?

  • Is the product to be produced considered mission-critical by the end users? How would the loss of the product affect their jobs?

  • Are end users generally in agreement on the need for this project?

  • Are there some examples of related systems that users particularly like to use or that were particularly successful in fulfilling their needs? If so, what are the characteristics of these systems the users found useful?

The discussion generated by these questions will help you understand the customer, their attitudes, and their likes and dislikes. This context will help you and the teams make better decisions during the course of the project.

Step 3: Getting to Know the Customer and End Users

Many projects often start with some sort of semisocial gathering, such as a luncheon. Often, the people who hold these gatherings assume they are for executive management only. I disagree with this position. The better the members of the teams know each other, the less likely they are to engage in political battles during the project. In addition, familiarity can open informal communications channels that can make the difference in project success.

The trend toward offshoring has made frequent in-person meetings between the customer, end users, and contractor team impractical. It will be interesting to observe the long-term effects of this situation. The concern is that the ability to communicate closely will need to be replaced by technological solutions to enable the communication. Without it, projects will suffer.

Maintaining Communication on the Project

Most projects are large producers of informationin the form of meeting minutes, status reports, trip reports, and so on. Like requirements, these are important project documents that need to be produced on a regular basis and retained.

Status Reports

Most customers require their contractors to supply written status reports periodically, often once a week. Most project status reports contain the typical summary of current activities, a section for planned activities, and a section for outstanding issues and risks. These reports, while important, need to be considered from the proper perspective.

Sometimes, the intended recipients do not read the status reports, except in certain circumstances. Some customers simply do not have time to keep up with the plethora of documents that cross their desks. I have learned the hard way that status reports should never contain new information that has not been previously communicated to the intended recipients. The status report is really more of a historical record; it should not be used to raise new issues with the customer. If you believe you must use a status report to raise a new issue, be sure to call attention to the issue by telling the customer separately (perhaps through an e-mail or a verbal comment) to be sure to look at that week's status report. Otherwise, you waste valuable time by waiting for a response that may never come.

Even though status reports are sometimes neglected, you should ensure that they are complete and accurate. When projects get in trouble, status reports and e-mails are often the only written records available. If the difficulties continue to the point where the contracts office and attorneys get involved, verbal comments and statements are insignificant. Status reports and emails become key because they are a record that is written by one party and reviewed by the other. Don't let poorly written reports become your undoing. Take them seriously, and be sure they are complete and accurate. At the same time, don't depend on status reports as the primary method of communication.

Status Meeting Minutes

Meeting minutes are useful as well. Depending on how frequently meetings are held on your project, formally prepared meeting minutes can help prevent misunderstandings. It is difficult to make a blanket recommendation for meeting minutes. If you have many informal and impromptu meetings, it may not be practical to create minutes for every meeting. The best possible solution for the least effort would be to record all meetings between the customer and contractors. If you meet electronically, recording the meetings may be a trivial matter. The advantages of recording meetings are several:

  • You are guaranteed an accurate record of all conversations that take place.

  • If you are unclear about what is discussed, you have an accurate record to return to.

  • Very little overhead is involved in recording meeting minutes.

  • If key people are unable to make it to a meeting, they can replay the meeting at a later date to catch up.

If keeping minutes is not possible or practical, at least create a written record of all key decisions that were made, as well as a list of all action items and who they were assigned to. Then, after the meeting, send the minutes to all meeting participants to ensure that no disagreements occur over what was decided and what the action items are.

Technical Interchange Meetings

On larger projects with multiple contractors, contractors might need to meet directly with each other, with or without the customer present. I have seen many large projects experience difficulty because of dysfunctional relationships between key contractors. Similar to building a relationship with customers, familiarity with your other contractors lessens the likelihood of political battles. Open lines of communication between the organizations at all levelsexecutive, contractual, technicalnot only lessens project risk but also makes for a more enjoyable experience, which contributes to good morale.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net