Friday, 13 February 2015 13:12

Handling Your First Multi-Year Project

Written by

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.

Read 9176 times
Robert B. Sowby

Robert B. Sowby is a project engineer in Salt Lake City and consults on a variety of civil, environmental, and water resources projects. He is also editor of the Wasatch Water Review (www.wasatchwater.org) and written a book called Learn to Launch.

© ProjectTimes.com 2017

macgregor logo white web