Every tech project needs a project engineer.
As a matter of plain and inescapable fact, no serious project can succeed without the right tools. Important tasks such as scheduling, source code management, test management, workflow management (defects, tasks, etc.), software design modeling, and many more cannot be run effectively on mere spreadsheets.
However, simply having the right tools is not enough. You also have to make effective use of them. This means your tools have to be properly set up and maintained, and it also means that every member of the project team has to be adequately trained to use them.
But even when you have all of these elements covered, they are still not enough, and the reason for this, while obvious, is often overlooked. And it’s simply this: in a typical project environment, tools are only partially integrated into the overall project design and workflow, if in fact they are integrated at all. This leads to confusion, redundancies, and an explosion of unnecessary complexity.
Unintegrated tools and the curse of busy work
For example, when checking files in a software configuration management system, a chaos of documentation is usually created over the course of multiple reviews. Assorted spread sheets, to-do lists, and bullet-pointed listings of planning tasks begin to pile up, all of them unconnected and redundant. Test cases are derived from requirements, but they are not explicitly linked with each other except by means of manually included IDs or by fragile naming conventions. Project reports are generated manually by entering current numbers into Excel sheets with redundant charts. And all of this must be done repeatedly!
I have actually seen projects where the development process itself generates 30 to 60 percent of the total workload. While this may conceivably result in better risk management, it slows down the actual work to an agonizing crawl, and it generates frustration among experts who, as a known personality type, passionately hate this kind of organizational red tape.
The irony is that this is not — or at least it shouldn’t be — a difficult problem to solve. Since nearly all tools offer powerful APIs, fixing these problems represents nothing more than a typical software integration task. It’s easy to design a tool that automatically generates review data for respective artifacts. It’s likewise easy to design a system that will provide automatic updates of project schedules whenever respective issues are closed.
We’re not talking rocket science or quantum mechanics here. A nice traceability management tool, one that will give developers a direct link from requirements to test cases, is quite doable using a variety of tools that are almost all currently available on the market. Similarly, project managers who dream of a comprehensive reporting system that fetches current data from various tools and then delivers a useful and convenient project status sheet can quickly turn this dream into a reality.
Or at least these things all should be easy. The tools to accomplish these things are there and just waiting to be used. But unfortunately, many projects still struggle with poor tool integration and the resulting redundancy and busy-work overload. Why should this be the case? What keeps so many teams from making full and fruitful use of the help that’s available?
The role of project engineer
In many cases it boils down to challenging managers and their teams to answer a simple but crucial question: who is supposed to do these things? Who should use the tools to create the systems that cut down on busy work? It certainly isn’t developers themselves who will never have enough time to “play” with tools, since they were hired for other purposes. It isn’t the project managers who usually have neither the time nor the required skills to tackle such tasks. On most teams, there simply isn’t anybody available to take on the task of integrating the necessary tools into the project in the most effective fashion. Consequently, the entire team wastes mind-boggling amounts of time and money on repetitive and boring “robot” work such as copy-and-pasting and manual maintenance of redundant data in various project artifacts and databases.
And so this brings us back to the opening point: every project needs a project engineer whose job is to address these very issues.
The role of project engineer, let it be noted, is most definitely not a job for interns. It is a job for highly qualified professionals, and it must be taken quite seriously. Through his contribution to the team, the individual in this position will remove most of the manual tasks that everybody else hates so much. He will create a set of tool integrations that work smoothly, ensure project data integrity (e.g., schedules, timesheets, tasks), and deliver an easy-to-comprehend working environment for everybody.
Return on investment
So why doesn’t every project have a project engineer? One reason is that it can be challenging to justify this role to project’s sponsors. Project engineers cost money, and it is difficult to create a “return on investment” calculation for their presence because the cost of making team members perform the repetitive, boring, irritating, error-prone tasks that a project engineer removes can be hard to measure.
But by the same token, it is also very difficult to justify many standard “common sense” project roles, such as configuration manager or quality assurance specialist. The presence of these roles on a team is simply assumed to be normal. The same reasoning must be applied to project engineers. We need to make sponsors understand that project engineer is also a “common sense” role, and that it ultimately saves far more money than it costs.
When I make this claim, I speak from personal observation. I have actually seen project engineers in action, and I can vouch that when one of them joins a team, all of the annoying little tasks that drain away time, energy, and creativity soon begin to disappear. Developers find they can focus on their actual core tasks. The entire team morale improves significantly.
I also have seen the opposite. I have seen projects where there is no project engineer and where the lack of integration among tools causes an avalanche of redundant work that does nothing to improve the overall outcome by improving the product in development.
The happy project manager
The role of the project engineer is an innovative project management idea. No “legacy” development process that I have seen has included this role. But today, this role finally seems to be gaining popularity, and rightly so, as its benefits become more widely recognized. Among these benefits is one that is often, and unfairly, ignored: it is simply a lot more fun to work in a team that is supported by an expert who takes pride in delivering a set of smoothly integrated project tools.
A happy project manager is one who has an effective project engineer. This is a point to learn, and remember, and factor into your future plans.
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.
Be the first to comment