Of the many factors that influence a project’s outcome, one key component is that everyone involved should agree on the characteristics of a successful project. Although this seems like a no-brainer, your staff’s definition of a successful project may be quite different from yours—a discrepancy that could cause serious communication problems between you and your team.
What could they be thinking?
The MBA part of my brain views project success as a fairly straightforward issue: The project should be on time, be within budget, and meet business requirements. Some people also add to the list the nice spin-offs you may gain as a result of a project, such as outside recognition, but that’s gravy—it's not core to the success of the project. How could anyone call a project successful if it is over budget, is late, or doesn’t work? Easy. His definition of success is different from yours.
In a recent Developer Republic Quick Poll of TechRepublic members, nearly 44 percent of the respondents cited criteria other than being on time, on budget, and functional as critical factors of a successful project (Figure A).
|What developers felt made for a successful project|
Understanding the disconnect
How could “I worked with great teammates” have won any votes? The short answer is that the what’s in it for me factor is the overriding sentiment in all of these choices. Self-interest is nothing new, but if you want to know what the cause is, here are some factors that may be precipitating this type of behavior:
- Artistic priorities: I have seen many developers who focus on the creative and shun the corporate. They know where their paycheck comes from, but the success of the company is not nearly as important to them as being creative and innovative. So while on-time and on-budget projects benefit the company, these concerns may not be a priority for the developers working on them.
- Wrong focus by project managers: To motivate staff members, your project managers may be focusing on the related benefits of a project, such as what a great opportunity it is to learn a new language. There is nothing wrong with that thinking, so long as the team keeps the bigger picture in mind. I have seen developers who think they are creating applications for the sake of creating them and forget they are there—in the case of an MIS department—to support a business.
- Every developer for himself or herself: It is also possible that the corporate culture in your shop is one that fosters mistrust, unhealthy competition, a mercenary attitude, and maybe even a hatred of your company. Whether you think that type of environment exists in your shop or not is irrelevant, because as the saying goes—perception is reality. And if your staff members have a negative perception of your corporate culture, it’s no wonder they feel the need to look out for their own interests.
- Unrealistic schedules or goals: You want a six-month project completed in one month. Maybe you have a vital reason for the rush; maybe you are just unaware of the time it will take to complete the work. Either way, your development staff will not take the project timeline seriously. At the same time, your staff does not want to fail. In the face of certain failure (with success defined by on-time, on-budget, and desired functionality), your staff members will change their definition of success to a realistic goal that they feel they can achieve. So even though they don’t have a prayer of being on time, they will consider the fiasco a success if they can at least say they learned something new in the process.
Changing the atmosphere
It will take heightened sensitivity and awareness on your part to determine which of these factors, or combination of factors, is at play in your domain. Managers who don’t want to deliver bad news or who always answer “Yes” are a liability to you, in this case. Once you have assessed the prevailing attitude in your development department, try these solutions to improve the situation:
- If your staff is unaware or uninterested, you need to make sure the right message is being delivered. Make them understand why your definition of success is important for them and for the company. Make sure that they understand how success on your terms can translate to good things for them. For example, one on-time, on-budget, functional project may mean more and better projects for the team. Or it may mean more and better equipment, facilities, or training. You get the idea.
- If your goals and schedules are not being taken seriously, make sure you are getting the proper information you need to make a decision, and not what your direct reports think you want to hear. Make sure there is appropriate communication between you and the people in the best position to know your department’s capabilities. And, if it comes down to the fact that you must move a mountain, remember that wishing it won’t necessarily make it so. You may need to redefine your own goals to make them meet reality.
- If your corporate culture is anything like the one described earlier, keep in mind that changes in this realm will be hard won and slow to come. You must first set the example by living the behaviors you expect those below you to exhibit. Second, make sure everyone understands the type of collegial environment you expect to see. And lastly, put people in place below you who exemplify the type of behaviors you want in your shop.
Get everyone in sync
The next time one of your projects is on a downward spiral and it seems like your staff just doesn’t “get it,” you may be right. Search for the source of the disconnect between you and your team and make sure everyone is working with the same definition of success.
How would you get things on track?
Do any of the situations in this article sound familiar? If so, how did you address the problem, and what advice do you have for your fellow CIOs? Send us an e-mail with your experiences and suggestions or post a comment below.