Any multidisciplinary development project can be tilted by one or more of its members. It helps to be aware of how other parts of the team may be affecting your ability to work code miracles and to realize that some of your job as a developer has nothing to do with writing code but with helping the project, or product, stay balanced. Here are some telltale signs that a project might be getting off-kilter—and some possible strategies you can use to get things back on track.

Who is on the team?
Whether your product is an object-oriented, enterprise application or a corporate Web site, the team assembled to carry out the development effort is likely to include business unit specialists (possibly the end users), business process specialists (the subject matter experts, or SMEs), marketing personnel, a project manager, a graphics specialist, a technical writer, an information architect, database staff, and you, a developer. You may have more than one developer on the team too. That’s a lot of people who’ll want their say.

Each member of your multidisciplinary team has been included to help turn out a well-rounded product. Nevertheless, it’s safe to say you should be most concerned about pleasing the group that’s bankrolling the effort. The customer, in this case, has the right to fully define the requirements and ensure that they are being met, in order of criticality, throughout the project life cycle.

Step up to the plate
Of course, you shouldn’t succumb to each whim of a hard-to-please business unit, nor should you let the marketing staff bully the project past deadlines over continually changing initiatives. Because inevitably, as your team defines business rules and previews a graphical user interface, you will unearth changes required to meet predefined business requirements. An iterative development approach can capture minor changes reasonably well. However, along the way, your customer will find new requirements, ones that will have to be appended, preferably in another phase, to the project.

Code gurus like you usually take pride in creating a product that is both useful and free of bugs. Unfortunately, that sometimes requires effort that has nothing to do with writing code. Here are a few signs that your project is off-track and suggestions for what you can do to make it right.

One team member (or group) is holding up progress or is not forthcoming with information regarding his or her responsibilities
Possible problem: The team member is overloaded or is uncomfortable with complexity of project.

Solution: Ask the project manager to lobby for relief in the form of additional, dedicated resources, training, or reassignment of staff to ensure the right mix.

The presentation layer appears overly complicated and is difficult to use
Possible problem: Too much leeway has been given to the graphics team.

Solution: Reel in the creative staff by working with them to reduce the user interface of the product to its simplest form and then add elements one at a time until harmony is reached.

The presentation layer is lifeless
Possible problem: There is too much influence from developers and not enough from the graphics team.

Solution: Back off a little bit and let other team members influence the application design. The look and feel of the presentation layer should be left to those most skilled in the aesthetics of the interface.

The team is unable to reach a course of action on a minor issue
Possible problem: There are unclear expectations for the item in question—or stress.

Solution: Clarify the issue with the right people, whether that’s the end user, management, or the developers. If the issue is beyond the technical grasp of the project manager, you might save time by clarifying the issue with the SME, who knows the way the applications should work. Buy donuts, relax, and rework the problem.

The team is unable to reach a course of action on a major issue
Possible problem: Design-by-committee has stalled the project.

Solution: It’s not always a good thing that everyone has input. Sometimes, you need to designate a seasoned and trusted team member to take the wheel, perhaps the application architect, who really is in charge and who can handle being personally accountable to the customer. Let that member make final rulings.

The documentation staff is having difficulty meeting deadlines
Possible problem: The writers don’t have access to the right people or resources or too many changes are being allowed late in the project.

Solution: Keeping documentation current with the anticipated release is a technical writer’s largest headache. If you don’t have time to sit with the writers to discuss the issues, make sure you thoroughly document your own code so that they can follow behind you to create useful user and administrative guides. Track changes properly using your source code control tools. Also, you may want to hint to the project manager that changes are hindering project deadlines, so that he or she can control end-user requests and expectations.

Database issues are holding up progress
Possible problem: The database team is overloaded or is uncomfortable with the complexity of the project, the data warehouse requires refinement, or too many changes are being allowed late in the project.

Solution: If the team is receptive, and you have the skill set, help define the scripts and offer to take some of the workload. Again, giving the project manager a heads-up that changes are hindering project deadlines might save everyone time.

Meetings are ineffective, and don’t result in action, or there are simply too many meetings
Possible problem: Project manager may be overextended or underskilled, or the project doesn’t have proper support from upper management.

Solution: Without stepping on the project manager’s toes, make your concerns known to your boss or a trusted coworker in a position to help. The project’s success largely depends on effective project management, and if you’re not moving forward, the whole team is accountable. And if you don’t have support from upper management for the product at hand, you’ll need someone who can lobby for the project so that management fully understands its importance and can allocate appropriate personnel and budget resources.

Keep it balanced
Ultimately, your multidisciplinary development team should be an efficient group that works together fairly seamlessly. A good project manager should manage customer expectations, subject matter experts should be able to choreograph the translation of the end user’s needs properly, and seasoned programmers should be able to properly separate business rules from business events and data from presentation. When you see that this is not the case, step up and try to get the team back on track before it’s too late.

Is your interdisciplinary group a team or a mess?

Have you been on an interdisciplinary team that has worked particularly well? What tips can you share to help others have an easier go at it? Send us an e-mail with your experiences and suggestions or post a comment below.