Network links go well beyond simple straight lines

Dennis Smith
Founder and CEO
CompanySmith Inc.
Linwood, Mass.

Bringing projects in on time, on budget, and with the needed features are such complex jobs that managers usually construct plans to outline individual tasks, show how long they'll take, and plot the interrelationships. The plans often contain estimates for times and costs, a trade-off between spending too much time planning and having a plan that reasonably represents the job at hand.

One approximation so common it gets little attention is the single line connecting two tasks in a plan. In Gantt and Pert charts, the line represents a relationship between tasks, and often indicates where one task stops and another starts.

But real life is not that simple. And the second biggest project lie is that the connection between two tasks is as simple as a line and a one-time hand off.

In a project plan, tasks represent what people do, and in any hand off between tasks, there are far more interactions than can be shown by a simple line. Interactions include resolving specification issues, getting “early looks” at designs to generate user feedback, explaining design decisions, providing prototypes for use in models, and a host of other events. With the growing use of virtual teams and offshore resources, understanding and facilitating the actions implicit in those single lines can make or break a project.

Teams should view and support hand offs as rich transactions between people. And there are ways to ensure teams function at the intertask level, as well as ways for project leaders to acknowledge and encourage the teamwork needed for projects to succeed.

IT'S NOT SIMPLE

Project planning is more of a science today than ever before. Through the works of the Project Management Institute and other organizations, the work and expectations for managers have been refined to where project management is well understood and documented and there is widely available training.

But the basics of project management are not well practiced. In fact, most companies I see still don't meet basic standards for project management. Rather, because interactions (or lack of them) between team members are not spelled out in project plans and are often not seen by project managers, the planners approximate all interactions with simplified links between tasks. The presumption is that they are “normal” relationships between people on the team. The teamwork that drives the people on the project is largely ignored.

Project mangers talk about “magic moments” or “golden moments” in projects, the moments when many project tasks and intermediate deliverables come together for project to proceed. Such moments often include final model assembly, finishing the software, or powering up a circuit prototype. The math on the likelihood of these events is simple. If it takes the completion of six tasks, and each has a 90% chance of success, the “magic moment” has a not-so-magical 53% chance of success.

Project managers build plans that minimize the number of “magic moments” by using incremental project processes and spiral-design methods, as well as rapid application development and implementation by evolving prototypes. These methods minimize design rework, get user feedback on controls and interfaces as early as possible in the project, and create milestones on the way to meeting project goals.

All of the factors driving projects toward incremental methods at the macro level are equally important at the micro level, the level of interaction between-two people in the project where one depends on the other. Yet in most project planning, microlevel interactions are left for those two people to work out and simplified to a single line of the project plan. But that line ignores the principles of teamwork required to make anything other than the most basic interaction a success.

So let's pull that single line apart and take a look at what it represents.

Often the first faulty assumption in project planning is that connecting lines represent one-way handoffs. In the real world, that is hardly ever the case.

Requirements in real projects are hardly ever complete when the project begins. Most companies start projects with less than half of the requirements documented, leaving the rest for design-time decisions. There have been internal IT projects that got board-level approvals with definitions even less complete.

There are exceptions. Military projects, aircraft-control systems, life-safety systems, and other special cases have much more complete definitions. But they represent a small minority of projects.

Therefore, many definitions are made during the project, so it is unrealistic to assume a single forward-flowing connection between tasks. Interactions have to be bidirectional. After all, the two parties must discuss undocumented requirements. The development process must also be interactive while both parties design their features with detail greater than what has been specified. There are also local tasks and commitments passing back and forth between the two as they negotiate the eventual completion of the first task and the transition of project responsibilities to the second task.

The hand off may be complete at a specific time, but the act of making the hand off is not a single point in time. Project managers look for specific measurable deliverables at the end of each task, and that is the right thing to do. But it's the interactions, clarity, and teamwork that really make handoffs.

Lastly, many project plans presume a level of mature and rational behavior between people at the ends of connecting lines. Successful projects have teams that debate, negotiate, and leverage each other. The more motivated they are to greatness, the more complex and intricate are the human and technical interactions in those simple lines.

BETTER TASK DESIGN

The first step to good teamwork in project management depends on great task design. Tasks should provide logical and touchable deliverables, be short compared to the overall project, sized for visibility, and allow control of risks.

Tasks also need to make sense. The clearer the task deliverable, the clearer the responsibility of the person performing the task. And the better the match between skills, assigned resources and tasks, the more predictable the project.

Eventually, task design reaches a natural limit when tasks go from motivational to micromanagement. At this point, the return on additional investment in the project plan is negative. It's time to set the plan prior to that point, set the baseline, and start executing the plan and building the team that will complete the project.

Since project managers cannot direct every detail and every person-to-person connection, there needs to be an approach that ensures person-to-person connections (defined by those simple lines) take root and support the work. This is accomplished by building teamwork.

While there are many methods to building teams, the standard method is by combining structured, project-related work with formal and informal social events. But afterhour get-togethers and Friday afternoon “keggers” are not as effective as they once were. Demands for balance between work and personal life have built a certain level of resentment toward “required” social events. Still, interspersing work with proper teambuilding events is a common way to foster teamwork.

Any activity for building working relationships across the team aids the project. Unfortunately the costs of “unapplied” team hours and consultants, and the number of weeks or months required for traditional teambuilding usually preclude these activities for projects that need them most, those that are late, over budget, and short on teamwork.

For projects that are near crisis and need better teamwork, there are tools such as Social Network Analysis to analyze person-to-person teamwork. Such methods give leaders tremendous insight into issues that may be affecting the project.

Building teamwork should be treated as an ongoing process as critical as the plan it supports. For projects already stressed, it is becoming increasingly more popular to use these tools to pinpoint teamwork issues.

COMMUNICATION

Communication builds teamwork. No communication, no teamwork. The goal is to create transparent communications between the two people on either end of that line connecting tasks. But the abundance of communications tools can help or hinder transparent communications.

Teams need to define and document the communication channels they will use and how often. E-mail's pervasiveness makes it the most common channel. In addition to agreements on basic e-mail etiquette, rules must include: how often it is read; maximum time for a response; weekend travel and holiday use; message length; banned purposes; and use of reply-all and of attachments. There should also be rules for other communication channels. If the team has not set standards, then two people on linked tasks should make their own. The sooner rules on e-mail use are made known, the better the chances are for effective teamwork.

If the team wants to use instant messaging, a service provider must be selected. It's amazing how many businesses use instant messaging but have not chosen a vendor for everyone to use. If instant messaging is used, then rules for e-mail could change. For example, two people might agree that anything that needs to be resolved in less than two business days needs to be done by instant message or telephone, not e-mail. The team might also agree that decisions made in instant messages must be quickly documented in e-mail or a shared workspace.

Shared workspaces are cheap, easy to use, and available to anyone with an Internet connection. Business security may limit options for shared workspaces for files, discussions, documents, and calendars. But maintaining one usually improves teamwork. And demands for a shared workspace grow as teams become more geographically or culturally diverse.

The most widely used shared workspace is Yahoo Groups. This service houses hundreds of thousands of private shared spaces. It is easy to use and set up, and it is pervasive in community-service organizations. It is also the place where many business teams go if their company does not provide “corporate” spaces such as eRoom by Documentum, Groove, Webex, or dozens of other offerings. Another interesting new tool for technically advanced teams is a shared, editable web site called a Wikiix.

With shared workspaces, e-mail rules change again, and this time it's a big win for the team. E-mails can now be considered read-and-discard communications. They can be used as pointers to shared spaces and attachments can become a thing of the past. The cumbersome act of filing e-mails and attachments by every team member can be replaced by a single document in the shared space. The two people linked in a task can even do all of their communication on the shared space and stop using e-mail. Radical? Yes. Doable? Absolutely.

The complexities of relationships and communications grow substantially when projects include offshore and remote teams. Although projects have been distributed to remote locations for decades, outsourcing's new visibility has raised the stakes of teamwork.

Offshore teams need less synchronous or realtime communications and more asynchronous communications — communications between people who are not working at the same time. This drives teams away from instant messages (except for periods when work days overlap) and forces them to use the phone and take calls during personal time.

Phone calls outside of business hours do allow connections, but eventually, people several time zones away from the home office will resent the intrusion of late-night and early-morning calls. Too often global teams become frustrated with the homeoffice attitude that the “business” runs on the home office's time zone, and people in other zones must bear the inconvenience it causes.

Shared workspaces inherently support asynchronous communications. Setting explicit rules and policies for all communications channels is an even stronger requirement for geographically dispersed teams. Shared workspaces have become virtually mandatory for remote teams.

So what should two people who must work together do if their organization lacks the foresight to define rules for using all these communication channels, including cell phones, faxes, Blackberries, home e-mail, and voice-messaging services?

They should take the time at the beginning of the task to define the communication channels they will use. It takes only a few minutes to go through the options and decide on a course of action. If the company does not provide a shared workspace, consider Yahoo Groups, if it's within your corporate policies. It can be up and running, and your partner or workgroup invited to participate, in under 15 min. It has limitations, but for short-term work, it is a rapid and effective solution.

BEATING THE LIE

Teams and their leaders must make every effort to provide and nurture seamless and effortless communications between team members, and especially between people linked by the line connecting tasks. Leaders have to provide appropriate project infrastructure and ensure everyone one knows the rules governing communications channels. Few teams set up these rules in a project's opening days, but clarity on communication methods is the third most likely practice to have a profound impact on project team performance. Only clear requirements for project deliverables and having a well-designed plan are more important.

Good communications between team members, sponsors, customers, and the leader is the best incremental investment you can make. With good solid communication rules and well-built working relationships at the person-to-person level, you may even make the biggest project lie go away. The biggest lie? “We understand everything that is going on in our project and it is under control, within budget, and on schedule.”