Author: Robert B. Sowby

How to Write a Project Vision Statement

A project vision answers why, the essential starting point for inspiring action.

A vision gives project participants a reason for contributing. It clarifies the project’s purpose, eliminates confusion, unifies the team, and inspires them to do their best. It’s of the three main points of my book Learn to Launch.

A vision and a vision statement are separate but related concepts. The vision is a grand, encompassing idea with emotional weight; a vision statement is its linguistic representation—a concise declaration of the big picture, a sort of project scripture. It sets the direction and helps people see and understand.

Consider the following examples:

  • “Take to market a copier that is small, inexpensive, and reliable enough for personal use on a secretary’s desk.”
  • “Design an onboarding program that quickly transforms new employees into valuable long-term contributors.”
  • “Prepare a prioritized list of low-cost engineering recommendations that guides the organization to more energy-efficient operations.”

Notice how these examples follow a pattern: “[Action] a [deliverable] that [criteria].” This pattern works well, but there are certainly other variations. Feel free to experiment and find your own.

One of the best project vision statements I’ve seen is “Denver to Honolulu on a hot day.” That may mean nothing to you, as it did to me the first time I encountered it. Aerospace company Boeing undertook its 777 program with specific objectives about a new airplane’s capabilities.


Advertisement

Following the format above, their vision statement may have read, “Manufacture a technologically advanced midsize commercial aircraft that strongly positions the company for the 21st century.” But the real specifications were too many to list, though a vision statement was crucial. Alan

Mulally, the 777 program’s general manager, simplified it with this beguiling phrase: “Denver to Honolulu on a hot day.” To the project team, it was obvious: deliver an airplane with high-altitude capacity (“Denver”) and extended operations (“Honolulu”) to be ready by summer (“hot day”).

What’s more, the phrase was visual and engaging.

Keep these points in mind when forming your own project vision statement:

  • Simple—Keep your project vision statement brief. If it is longer than a sentence or two, it’s not clear enough.
  • Actionable—Express the project vision with strong verbs like “deliver” or “produce” to encourage action.
  • Engaging—Include concepts that will resonate with project participants and impel them to commit their best effort.
  • Collaborative—Solicit input from many stakeholders, including your team and the client. This will not only produce better ideas but will help them own and agree on the vision.
  • Forward-thinking—Imagine the project’s conclusion and express the vision in terms of the benefits.
  • Specific—If they are brief, you may mention a few key criteria or goals that will define success.

As great as a vision statement is, it doesn’t substitute for a detailed project plan. Your vision statement can’t possibly include all the goals, expectations, criteria, descriptions, and definitions necessary for the project, and though it refers to a few, it doesn’t define them concretely. The vision statement is only useful when participants grasp the underlying details and the vision statement itself is just a reminder.

While you aim to articulate a clear vision from the very beginning, remember that your vision may evolve as the project unfolds and you learn more about the problem you are solving. If needed, rewrite your vision statement. And rewrite it again.

Why You Should Cross-Train Your Team Members

Cross-training, where one team member learns to do the job of another, offers numerous benefits to project teams.

I’ve seen it myself in numerous projects and teams, with positive short-term and long-term effects.

Here are the top five benefits of cross-training as I see them:

  • Reinforced learning: Teaching someone a new skill makes the teacher view that skill from a new perspective and think critically about how the learner should approach it, reinforcing their own previous training and providing new insights that benefit the team.
  • New relationships: The collaboration enables new relationships to form that may not have otherwise. These new connections foster collaboration and inject doses of energy, creativity, and esprit de corps into the project.
  • Organizational awareness: By learning each other’s roles, your team members will better understand how each part fits in the project. Rather than working in isolation, team members understand how their work affects each other. This can help identify duplicate or unnecessary work and improve productivity.
  • Robustness: Cross-training makes your team more robust by allowing work to continue during absences when it would otherwise halt. Team members may have to leave temporarily or permanently for various reasons and cross-training ensures that the disruption is minimal. (In performing arts, this is the purpose of an understudy—a performer who can replace someone in a critical role during an emergency. The show must go on!) Cross-training is especially important for long projects where staff turnover can be significant.
  • Capacity building: Cross-training allows you to harness internal talent on the current project and build capacity for future ones. Roles will change from project to project, so cross-training will help prepare team members for the next one.

Advertisement

Global design firm IDEO, famous for its seemingly bottomless innovation capacity, leverages cross-training and cross-disciplinary capabilities in its project teams. CEO Tim Brown described IDEO employees as T-shaped people. “The vertical stroke of the ‘T’ is a depth of skill that allows them to contribute to the creative process. … The horizontal stroke of the ‘T’ is the disposition for collaboration across disciplines. … T-shaped people have both depth and breadth in their skills.”

Cross-training helps turn I-shaped workers—those with depth but no collaborative propensity—into T-shaped workers. They learn to listen to other points of view, build on each other’s ideas, and produce synergistic solutions rather than settling for compromises.

Consider dedicating a portion of your team’s time to cross-training. Much of it will occur naturally as team members collaborate, but you may need to structure more deliberate training on certain skills.

Great project teams continue to learn. Through cross-training, they hone skills in their individual areas of expertise and also learn basic management, communication, and interdisciplinary skills that benefit everyone.

3 Keys to a Successful Project Kickoff

Kickoff sets the tone for the entire project. You need a powerful vision, team, and plan to drive it.

I’ve led or attended dozens of or kickoff meetings, from small internal projects to large multi-year programs. In my experience, regardless of size or setting, the most successful ones focus on a trio of big-picture items: a vision, a team, and a plan.

Project Vision—Why

Inspiring others to act begins with why. During the kickoff meeting, share your vision for the project. Guided by the charter, explain why you’re doing it, why it’s important, and why it aligns with organizational goals.

Related Article: Managing the Kickoff Process

An inspiring vision unifies and motivates the project team to act. Communicate it clearly up front. Steve Jobs said, “If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you.”

Project Team—Who

Who will fulfill the vision? Team members must work together throughout the project, so they should start off on the right foot. Though informal planning meetings have already occurred, kickoff is an opportunity to formally acquaint everyone. Have members introduce themselves, describe their skills, and explain how they hope to contribute. During the meeting, establish an expectation of collaboration. Encourage participants to share ideas and ask questions. Allow time for networking after the meeting.

Kickoff is the time to discuss everyone’s roles and begin team development. As Henry Ford said, “Coming together is a beginning; keeping together is progress; working together is success.”

Project Plan—What, How, When

Now that you know why you’re doing the project and who’s involved, the project plan defines the remaining details. You’ve already developed a charter; now share it with the entire team and get consensus.

The scope is the what—a suite of tasks designed to meet the goals. It specifies the size of the effort, what is and isn’t included, and how tasks are organized. Refer to the charter.

The approach is the how. What processes will we use? What assumptions are we making? How will we make decisions? How will we communicate? Get everyone to agree on how they will complete the work.

The schedule is the when. It specifies deadlines for individual tasks and milestones. A commitment to schedule encourages teamwork and on-time project delivery.

In the words of Alan Lakein, “Planning is bringing the future into the present so you can do something about it now.”

Beyond the Kickoff Meeting

While the meeting is the official beginning, kickoff is really more of a process than an event. Revisit the vision, the team, and the plan periodically to maintain the big-picture and promote optimal project performance.

Handling Your First Multi-Year Project

sowby Feb18

Before becoming a full-time consulting engineer, I had never encountered a project that took more than a few months. Besides my master’s thesis, all my previous educational and professional work had involved narrow scopes, short timeframes, well-defined processes, few alternatives, and more or less predictable outcomes.

One of my first consulting assignments was a comprehensive, countywide stormwater study, the first of its kind for our client. The project would span three years, require thousands of staff hours, and involve a consortium of three consulting firms. At first I was overwhelmed by its ambitious scope, having never encountered a project nearly this large before.

Now that the project is complete and the client is satisfied, I can reflect on what I learned along the way. In addition to established best practices, I have found these five lessons particularly useful.

Be prepared for turnover

In the project’s second year five team members changed jobs with little notice. Each loss stalled the project and caused confusion as we scrambled to regroup. Those team members’ knowledge about their own data, tasks, processes, and resources was difficult to replicate in their absence. There was even a four-month period where no one—especially the client—knew how the project would turn out with so much turnover in the project team.

We had assumed, subconsciously but erroneously, that the project team would remain static for the entire duration of the study. But working with three consulting firms—two local firms and one multinational corporation—we should have anticipated some turnover and developed a contingency plan. We might have better educated the entire team on the project’s objectives and schedule. We could have assigned team members to work in pairs and cross-train each other on their workflows. Team members could have documented their work more carefully along the way and checked in with supervisors more frequently. We could have established a policy that an exiting team member must provide a verbal and written status report before departing, noting what their responsibilities were, how they performed certain tasks, where they left off, and where to find their files.

Organize digital and physical files

At first we had very few files, mostly for project startup by the project manager. We saved everything in one folder on our server and had few hard copies. But as the project gained momentum and other workers joined the team, the files quickly multiplied. Files for simultaneous but discrete tasks, such as data collection and criteria development, were housed in the same folder. Memos, spreadsheets, scans, agendas, and GIS data were floating in what had become a pot of digital alphabet soup. Team members struggled to find the right file, sometimes picking up one which was obsolete or from the wrong study area.

We soon realized the need for a more defined structure since the project involved four geographic study areas, several major tasks, and many data types. We developed a system for organizing both digital and physical files. Computer files were organized by study area, then by activity or data type. For example, the directory for Study Area “A” included subdirectories for Criteria, Data Collection, Design, Mapping, Hydrology, Project Management, and Report. Everything relevant to the study area was located in one directory. We later added and “Old” folder for old versions or obsolete files we didn’t feel comfortable deleting entirely.

Hard copies were stored by individual team members in their own workspace, but where the in-house team could still access them if needed. One day a fellow engineer needed a particular map, which I kept in my office, to answer a client’s immediate question. Though I was away, my co-worker quickly located the clearly labeled folder on my shelf and retrieved the map.

The same file structure was replicated for each study area as the project progressed, and was even adopted by other projects. With a well-organized and functional file system, the project proceeded much more efficiently. We modified the structure over time and ultimately found a system that worked well for us.

Document meetings and decisions

The project involved dozens of formal meetings and hundreds of informal ones. Each meeting—whether with the client, the project team, or the public—often produced key decisions or revealed important issues. We aimed to capture those items in writing during or soon after the meeting, and to distribute the meeting notes to attendees within one business day.

The format differed depending on the situation: sometimes a brief email, sometimes a photo of a whiteboard, sometimes an annotated agenda, and sometimes a more detailed memo. Whatever the format, we kept a record of our meetings and other important communications (such as conference calls or special problems) and shared notes with interested parties soon thereafter.

Near the end of the project, the client questioned some of our design criteria and implied that we might need to redo some work. We referred them to notes from one of our initial meetings with them, a design criteria workshop. The notes, which were shared with the team and the client the day after the workshop, documented how we had discussed the criteria, received the client’s input, agreed on the criteria together, and decided to proceed. After reviewing the notes again, the client remembered why we had selected those criteria and allowed us to complete the project without repeating any work. The meeting notes also helped us respond to important issues and compile the final report.

Listen and learn

Fresh out of graduate school, I felt I possessed valuable knowledge and was eager to contribute. I quickly found that I still had to learn certain things that cannot be taught, like the company’s culture, the project manager’s style, the methodology specific to this type of study, and regulatory conditions that drive the type of work we do. I needed to become familiar with people and protocol, with objectives and processes. I found that my technical knowledge was specific but limited, and that my skills were valuable but isolated. The project was just what I needed to apply and test my abilities in a broad range of tasks.

Throughout the project I adopted an attitude of “listen and learn.” I observed how the project manager developed a meeting agenda and adhered to it. I learned why the client needed the project and understood their objectives. I listened when the project manager provided feedback on my work and mentored me on how to improve. I noted each team member’s role, their strengths and preferences. I came to know the processes and challenges in conducting this type of study. I saw the project as an opportunity to be a sponge, to absorb as much as I could from my teammates and the engineering experience.

Communicate regularly with the project team and client

Regular check-ins with the project manager and our in-house team helped us keep the project on track. Such encounters were usually brief, informal, unplanned events, such as asking about a particular dataset, reporting on my task status, or confirming a meeting with the client. For me, these check-ins served three purposes: to make the project manager aware of my activities, to get an update on project status, and to ensure that I didn’t pursue the right task in the wrong way or at the wrong time.

The last purpose was particularly important, as there are multiple ways to complete a given task, though the project manager may have a preference. Before launching into a new phase or task, I would confirm my understanding of it with the project manager. We discussed objectives, inputs, outputs, data sources, level of detail, expected effort, and how the task fit in with the overall project. This practice contributed to efficient use of company resources and timely project completion.

Likewise, regular contact with the client ensured that they understood our progress, that we were meeting their needs, and that our approach was appropriate throughout the three-year study.

These lessons have helped me be successful in this and other projects. Certainly, every project is unique. While these practices derive from one particular project, I have found that they can apply to a variety of projects and situations.

Don’t forget to leave your comments below.