December 2019 - Edition 08, Managing Teams
Introduction
It’s the holiday season, but you wouldn’t know if from the weather. All work related activities are winding down while preparations for festivities ramp up. It brings into stark relief how some of the skills gathered as engineers can come into use outside of our work. Just this last week I had to troubleshoot lightbulbs, set up ladders safely, calculate the length of additional light strands, etc. One skill that certainly comes into play is managing all the tasks that need to be accomplished with a minimum of hassle. Which is my poor segue to this month’s topic – management of technical teams.
Demetri's Corner
During this down time, I’ve been taking some time to reflect on the future of the company and do any training that I’ve been neglecting. I should probably be more proactive about organizing files, closing out the year, and all the other administrative tasks, but it’s hard to get motivated when holiday festivities are grabbing your attention. Even so, work must go on, so however distracted, things are moving forward.
I am continuing my push to increase the visibility of SES on my website and have set a goal of posting one newsletter and one new “item” each month. I thank all of those that take a few minutes to check in and welcome any comments (both good and bad, I can take it).
Today's Subject - Managing Technical Teams
It’s probably an understatement to say that at this point of my career I’m more of a manager than an engineer. I love the classical engineering discipline, but I’ve come to realize that my real value is in management. I have always been an “integrated thinker” which results in my having a very good understanding of the forest, but often lower levels of interest in the trees themselves. Luckily, I have had the opportunity to work with many talented engineers that love trees, and with little direction make the forest I envision possible.
There is tons of information out there about project management. I’m not trying to claim that I have better insight on management and control of projects generally, but instead focus on how technical teams are managed. I will use many of the same terms and principles frequented in the project management community to maintain consistency and correlation with standards such as Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK).
The Time Periods of a Technical Project
Like all projects, there are generally three distinct time periods for a technical project: project initiation and planning, executing and monitoring, and closing. Project initiation and planning sets up the tools needed for properly defining the problem and the method of solving the problem, where execution and monitoring gets work done and makes sure the right work is being done. I’m not going to talk to the last time period as it’s generally company, industry, and/or project specific with little technical impact.
Project Initiation and Planning
When managing technical teams, this time period is the most critical to ensure project success. My experience is that when engineers know what they’re doing, why they’re doing it, and how they should do it, they tend to operate more efficiently and effectively. It provides a sense of ownership of the problem and solution. As I’ve discussed in past newsletters, ownership is a critical aspect of empowering engineers to do their best work. So, let’s delve into these three areas of project initiation and planning.
What is Being Done?
Before a project starts, generally there is a vision on what is required. Something like, “analyze seismic loads on the electrical cabinet”, or “determine neutron flux at location Z”. This generally comes as a customer requirement. Generally, the information is transmitted by contract, or in some attached requirements document. It defines the end result of the project and doesn’t get into a lot of details on process. In project management speak, it would first show up in the Project Charter, and then as part of the scope statement.
For technical teams, we need to make sure the ultimate vision is realized by the project, but I don’t want to focus on this too much as it stifles creativity. Often the end goal will change during a project and revision is needed. This can be due to incomplete understanding of what is needed when the project starts, changes that occur due to findings during the work, or changes to the requirement from outside influences. To take the electrical cabinet as an example. Execution of the project may determine that what is really needed is to know how much margin is available to the provided seismic loads. The requirements then change to, “determine margin to failure during seismic loading”. To be able to make this change requires understanding why the work is being done.
Why Is It Being Done?
For a technical team, the why is often more important than the what. This is especially true when trying to build empowerment in a technical team. Engineers generally like being given a discrete and definable task but want to understand why they’re doing it. This is in contrast to some other industries where compartmentalization of information and motivations can result in more focused and efficient work towards an intermediary goal. Computer programming is what comes to mind, but construction and production facilities are similar.
Going back to our electrical cabinet example, the reason for doing the analysis may be to ensure that a new set of seismic spectra will not overstress the cabinet. These new spectra resulted from some reviews of historical data and new data techniques. During the start of the project, the new spectra seemed pretty solid, so determining the stresses are not exceeded by the spectra seemed appropriate. During project execution, engineers may realize that the industry is continuing to refine seismic models and the potential exists for additional changes to the analysis inputs. In my experience, a well informed engineer buried in the analysis with knowledge of why they are doing the work will raise a flag at this point and question whether consideration of only the provided spectra is sufficient. This is what would drive a change to the requirements of the project, so the outputs can be more flexible and accommodate future changes.
What I’m trying to highlight is that we will never know everything when we plan a project. Likely nuances that could have real impact are missed during project initiation. This is where we must lean on our talented “doers” to help us be successful. Engineers executing the work are far better positioned to recognize when the “what” and “why” are no longer in alignment.
How are we Doing It?
The first two topics are the most critical, and in simple projects may be the bulk of initiating and planning the project. But how the work is going to get done is required, though can be highly variable in detail. In the case of the electrical cabinet it could be as simple as: perform analysis, check analysis, review/approve analysis. In the case of the flux example it could be, “determine core condition, define model, establish inputs, validate software, verify and validate model, perform analysis…”
Standard project management tools are used for this in terms of scheduling, resource management, cost, etc. This is covered in great detail in the PMBOK and I can offer little in terms of additional value. But for technical teams, the most important aspect is integration of the engineers in the process. Too often non-technical managers, or managers from different disciplines than the project work are tasked with defining the “how”. That leads to several problems such as:
- the work progression is not typical and results in confusion,
- technical teams are not structured to accomplish the work as planned,
- the planned activities are not sufficient, or properly characterized,
- sequencing of activities is non-sensical, and
- worst of all, the engineers feel like they were locked out of the process.
Project managers shouldn’t force engineers to put together schedules and budgets. Instead they should put together an early “straw man” for review by the engineers. A lot of negotiation and listening must be performed at that stage so that the concerns listed above are minimized. This should include a discussion on roles, responsibilities, reporting, etc. The final result should be a plan for getting the work done that the engineers feel some ownership in generating, but the project manager put together so that monitoring of progress during execution is effective.
Documentation
The primary documentation during initiating and planning a project is a Project Plan. There should be no exception to provisions of this document. It could take the form of a few pages that outline the information above (along with some additional information discussed below), or a significant document with appendices, detailed schedules, cost breakdowns, etc. The scope of the Project Plan is entirely dependent on the complexity of the effort and its importance to success. Note that cost of the project was not a criterion. Cost of the overall project has no bearing on how much initial planning should be performed as the purpose of the planning is to ensure technical success, not meet a budget. If the project cannot be performed within budget based on the planning costs alone, either the budget should be increased, importance to success decreased, or complexity decreased.
I’ve focused on the what, why, and how for a project above. There are other items that must be addressed at this stage of the project. At a minimum, the quality requirements and risk management must be addressed in the Project Plan. These topics have been covered in past newsletters, so I’m going to forego a detailed discussion.
Executing and Monitoring
As I stated at the beginning, the initiating and planning aspect of projects is the most critical part when working with technical teams. Giving them the information and empowerment to be successful will pay dividends during execution. Nominally, a project manager for such an empowered team has little to do other than monitor progress and maintain the relationship with external stakeholders. This is an enviable position for any manager. Of course, things go wrong, but the consequences can be minimized if three tenets are followed during this time period.
Stay Informed
As a project manager leading a group of engineers that are self-motivated, it’s easy to unplug and let them take care of the work. This temptation must be avoided and a manager of technical teams must stay constantly aware of the work being performed, issues being resolved, technical details on progress, and administrative roadblocks. This requires regular check-ins with all of the team members, continued learning on the technical aspects of the work being performed, and informal conversations to determine whether there are lingering issues that could result in greater downstream concerns. In some cases it doesn’t hurt for the manager to be part of the executing team as it builds technical credibility, increases the number of interactions, and increases overall project knowledge. In this manner, managing technical teams is different than managing other industries. Nobody would ever expect (or want) the project manager on a construction project to swing a hammer.
Stay Out of the Way
This is the counterpoint to the previous tenet. The two must be balanced. Unnecessary interruptions, meetings, reporting requirements, requirements changes, etc. only serve to frustrate engineers. It also undermines their authority to make decisions, which is not productive. In general, technical teams should be less micro-managed than professions where workers have a very limited scope. Faith has to be placed in the training, intelligence, and commitment of an engineer instead of assuming that management is best leveraged to direct daily work. This does not mean unplugging (see above) but looks more like command by negation.
Perform Aggressive Course Corrections
Sometimes things just need to be fixed. Either schedule, cost, or scope has gotten out of control, new revelations have been made, or unrealized risk has impacted the project. In these cases it is not enough to work around the margins and try to fix it with minimum disruption. Engineers need a direct approach to problem solving and a clear understanding of the problem, proposed solution, and implementation strategy. Changes to the project to address concerns must be clear and well communicated. Some recommended approaches to providing clear course correction are listed below.
- Revise the Project Plan. Make sure the entire team is aware of the revision.
- Hold a large meeting. This is one of those times were the tenet of staying out of the way is not an option. A large meeting is a good way to get attention and make sure everyone knows this is important – especially if such a meeting is rare.
- Openly discuss the issues. This pertains to situations where the team may be losing control of the project and the focus needs to be re-established. These conversations are hard as one or more people are going to be called out as endangering project success. Luckily engineers (the good ones) have thick skin and can take the criticism as long as it’s constructive and a potential solution is brought to the table.
Summary and Conclusions
There are loads of people that perform project management as a trade, and they are very skilled at the mechanics involved. Over the years I have also developed most of the mechanics and know-how to use the standard tools and processes, either by self-study, guidance from experts, and observing what works. When it comes to managing technical teams, all these skills are useful, but the mentality of an engineer and the requirements of engineering projects must be considered.
I can’t emphasize enough the importance of getting the project started off on the right foot. Too often I see this part short-changed for purposes of saving money. The areas first put on the cutting board are:
- activity planning,
- risk identification and quantification, and
- identification of roles and responsibilities.
It’s not surprising that these are the first to go as they are some of the most expensive and contentious processes. There is a reason they are expensive (time-consuming). It’s because they are important and hard to do correctly. Conversely, items usually never cut from the planning process are less important when you have an informed technical team or properly define the items above. They include:
- detailed scope statements and WBS dictionaries,
- resource leveled schedules,
- cost analyses,
- quality requirements,
- communications strategies, and
- stakeholder engagement.
These items either tend to work themselves out during execution with the technical team, can be inserted into the project by the technical team directly, or only result in incremental value due to the high unpredictability of most technical projects.
During execution, a manager must find a way to be intimately involved in the technical direction of a project without getting in the way. Generally the easiest way is to be part of the technical team in some role so they’re not imposing additional overhead to the project in terms of communications, reporting, etc. Finding this balance can be hard since a manager coming from a non-technical perspective will find it difficult to integrate into a technical team, and a manager coming from an engineering background will find it difficult to limit their technical engagement so they can continue to serve as a project manager.
I find managing engineers incredibly rewarding. As much as I think I’m pretty technically strong, I’m well aware that other engineers are much more adept at the technical side of the industry. I can’t imagine a better use of my skills than to enable teams of engineers to accomplish so much more than any one engineer could individually. Hopefully this newsletter has provided some insight on what I’ve found useful and motivated more engineers to consider technical management as a skill worth pursuing.
Dose of Aphorisms
I thought I would do a weird one for this newsletter. I’m always remembering my time in the Navy, so ship driving aphorisms (and those involving cars) are my favorite and therefore most colorful. Even if you know exactly where you need to be and how you can get there, your “sea state” may change requiring a new approach so you don’t capsize. So even though it’s tempting to stick with a good plan, the conditions may necessitate a different approach to keep from swamping the ship.
Project Management is like navigating on the high seas. Sometimes you have to crash through some swells head on, even if it’s not entirely your intended direction.
P.S. I’m not entirely sure this isn’t also true for engineering development, but that’s a subject for another newsletter.