Does a Project Manager Need to be a Technical Expert?

Does a project manager need to be a technical expert to manage a technical project?  The answer is an unequivocal, “Maybe!”

To more fully answer this question we need to understand the primary responsibilities of the project manager on a technical project.  The Project Management Institute defines the Project Manager role as, “The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.”  Two phrases jump out of that definition, “lead the team” and “achieving the project objectives.”  Let’s examine each of those and see where that takes us.

Lead the Team

There are hundreds of definitions of team leadership.  They each emphasize various personal attributes and skills of the leader.  I am going to focus on three that I believe are very important in the project management context, trust, communication, and decision-making.

For trust to grow between a project manager and the project team, two things must exist, integrity and relationship.  The project manager must build a relationship with the team members and stakeholders and that relationship must be grounded in integrity.  If the project manager does not have a relationship with the team members, he or she must quickly develop one.  In building that relationship, the project manager and the team must be honest with each other in order to build trust.  Through that relationship building the team will come to understand the strengths and weaknesses the project manager brings to the team.

So how does technical expertise impact trust?  The project manager should not pretend to have expertise they don’t have.  When the true level of expertise is discovered by the team, they will conclude they have been lied to and that project manager will never regain their trust.  The project manager must be comfortable saying, “I don’t know.”  By the same token, with the development of a relationship based upon integrity, the team will gain confidence in the project manager. 

Communication is vital in project work, both within the team and between the team and project stakeholders.  Normally, the project manager leads the communication activities of the team. 

When a project is highly technical, the project manager must be able to communicate about technical issues and progress.  While they do not need to be the technical expert on their team, they need to obtain enough technical knowledge to communicate effectively within the team and with stakeholders.

The third element of leading the team is decision-making.  Due to the unique nature of technical projects, they are full of decision that must be made by the project manager or the project team.  These can’t be pre-determined because the decisions rely on information, designs, and data that are generated within the project.  Failure to make timely decisions on a project will lead to delays and overruns.  But of course making a bad decision can also lead to delays, overruns, and even project failure. 

If the project manager is not technical, they need to establish a clear and fair process for how technical decisions will be made. This process needs to be understood by all team members and it needs to be followed.  In some organizations, the culture prefers authoritative decision-making rather than team decision-making.  In those organizations, a technical person needs to be in the decision-making role on technical projects.    

Achieve the Project Objectives

Since we have already discussed some of the people management aspects of the project, I am going to confine the discussion on achieving objectives to the creation of an appropriate project plan and managing the risks to the project during planning and execution.  In order to have any level of confidence that objectives will be reached, a plan is needed.  However, since we are talking about technical projects, there is inherently a level of risk in the use of the technology that must be proactively managed in order to achieve the objectives.

Project plans on technical projects will typically include design activities, test activities, analysis activities, and documentation activities.  There are often numerous tasks in each of those categories.  In order to accomplish those tasks, technical expertise is required.  However, if there are team members who have the expertise and are assigned to the tasks, there is no need for the project manager to have the expertise. The larger concern is the project planning.

The creation and maintenance of a project plan is the responsibility of the project manager.  When an organization has project templates for technical projects that include estimating guidelines and lessons learned from other projects, the project manager does not need to be a technical expert.  They can rely on this information.  However, if those don’t exist, the non-technical project manager will need to rely on the team members to provide that insight.  If the team is inexperienced, they should not be assigned a non-technical manager.  If the team is experienced and the project manager is able to quickly build trust, he or she does not need to be a technical expert.

The final point of discussion is risk management.  A major portion of a project manager’s job once the plan is in place is to monitor the project to identify and resolve risk and issues that will prevent the project from achieving the objectives.  An informal survey that I did with about a dozen experienced project managers indicated that they spend two thirds of their time managing risks and issues.  Their goal is to catch and resolve them when small so that they don’t become big.

The project manager should be relying on his or her team members to identify risk issues in their area of expertise.  The project manager then helps to resolve those and seeks to identify risks or issues from outside the project along with risks or issues on integration within the project.  Technical expertise is definitely an advantage when identifying and resolving risks.  Although if the project team is experienced and there is a lessons learned database or other project histories available, a non-technical project manager can manage the project risks.

Conclusion

So what is the bottom line?  If there is an established and robust project management methodology and the project team is comprised of experienced experts, a non-technical project manager can be effective as long as they quickly build trusting relationships with the team.  If those are missing or if the organizational culture demands an authoritative project manager – they need to also have technical expertise.

Project Dashboards

Thanks to the growth of Business Intelligence, dashboards are proliferating in companies today.  Dashboards are providing real-time, or near real-time, information to managers and supervisors on virtually every business process and every product offering.  The use of dashboards by project managers is becoming common, yet there is not a corresponding improvement in project management and execution.

So why are dashboards often ineffective as a project management tool?  Is there too much information, not enough information, or the wrong information?  Do project managers lack the skills to read and understand what the dashboard is telling them, or do they lack the confidence that they can trust what the dashboard says?  Are dashboards an appropriate tool for managing projects?

To answer these questions we need to understand what a dashboard can do well and what it cannot do well.  Then we can consider how to best use it in the project environment.  Finally, we need to determine how to prepare and equip our project managers to use a dashboard.

Dashboards

A business dashboard is an information management tool used to track key business metrics and other data relevant to managing a business unit, department or process.  Often dashboard use data visualization tools to display the metrics in charts and graphs and allow drill down to underlying detail data elements. 

The dashboard metaphor is very applicable.  The driver of a vehicle does not drive by looking solely at their dashboard; rather they are watching the road and frequently glancing at the dashboard to determine if everything is operating as expected.  If the dashboard shows they are going to fast or slow they change their speed.  If it shows that they are low on fuel, they stop for a fill-up.  If the warning lights are on or a gauge is in the “red zone” it indicates a problem and they begin to take preventive and corrective action to restore the vehicle to a proper operating condition.  The same is true with business dashboards only instead of a vehicle it is a business unit, department or process. 

Think about your dashboard for a moment.  It requires real-time information to be helpful.  Showing the speed that we were traveling yesterday is meaningless.  Showing the fuel level of the vehicle from a month ago is useless information.  Likewise, the dashboard must provide information about key performance indicators to be helpful.  For instance, providing the temperature reading of the outside air temperature does not tell me if the engine is running hot.  Measuring the acceleration time from 0 to 60 mph may give you bragging rights at the drag strip, but that measure is irrelevant if I am driving across town to visit relatives.  So instead my dashboard shows fuel consumption and if I entered the address in the GPS, it shows time and mileage to my destination which are far more practical.

Project Dashboards

So what is the implication for project management?  First, the project dashboard must have real-time information.  That means we can’t wait for a weekly or monthly team meeting to update the dashboard.  Don’t get me wrong.  Those meetings can be very useful team integration and team decision-making.  But waiting for a week or a month to find there is a problem with the activities on the critical path is unacceptable.  This means that either the project team must gather at least daily to update status or there must be some other system measurement that is collected frequently and can be used to track project performance. 

Agile/Scrum projects use the first approach.  They gather every day, sometimes more often, for a scrum meeting to update their Scrum Board and Burndown Chart – which are two dashboard views for an Agile/Scrum project.  Some collaborative project management software attempts to provide real-time information through daily status reporting of project tasks by all project team members.  

When properly implemented both of these systems can work well.  However, not every project is suited to Agile/Scrum (see Blog post “Choosing the Best Project Management Methodology”).  For the other approach, setting up the baseline project plan in the project management software can be very time consuming and frequent changes are almost impossible to maintain.  Not to mention, now all the project team must be trained and disciplined to provide status on project tasks.

So what is the answer?  Forget about project dashboards?  Add people to the project team that spend all their time creating and maintain dashboard data?  How about create a pretty chart with random data we can easily measure, give it to the PMO and hope they leave us alone?  Of course none of these are palatable.  Instead, we must find a way to simplify the dashboard so it can be easily created and maintained, but still have useful information.    

Project Dashboard Metrics

Where do we start, start with the risk register.  Think about your automobile dashboard again.  If your vehicle was built during the last 30 years, it has tons of sensors embedded in it.  All of that information does not get displayed on the dashboard, only information useful to the driver while driving.  In particular, information that tells the driver if there is a problem.  So your project dashboard should provide meaningful real-time information about project risks.  Now there may not be a direct measure of risks, but often there is an indirect measure or leading indicator of a risk.

Let’s say you have resource availability as a major risk on your project.  Track the number of hours spent on project tasks by all project team members each day.  You don’t need a breakdown by task and by minute where they spent their time; just determine if they were available.  Or let’s say that a major risk is the late delivery of an item from a vendor.  Request weekly status reports until within one month, then daily status reports of the vendor’s schedule progress.  You don’t need a full vendor audit each time, just a schedule update (which you should periodically validate).  This provides an early warning of a potential delay and gives you a chance to take corrective or preventive action. 

Conclusion

The point is to determine the simplest way to get real-time data about the risk condition and place that on your dashboard.  This doesn’t overwhelm the project team with unnecessary reporting about low risk, routine activities.  Yet it provides valuable insight about the things that the project manager should be most focused upon.  Remember you are not driving the vehicle by only watching the dashboard; rather you use the dashboard to confirm that all is running well or to take corrective and preventive action.  

Five Tips for Process Improvement Projects

Many small projects are focused on improving an existing business process.  The process works but it is slow, error-prone, and creates complaints and frustration.  Other higher priority projects were ahead of it, but now it is finally time to work on that process.  Here are some tips that apply whether it is a technology/system process, and administrative process, or an operations process.  Of course, you need to do the typical project management activities of planning the scope, schedule and resources; then tracking the activities to determine if you are on plan.  But these tips are to address some things that are unique to process improvement projects. 

1. Win Supervisor Support

We have all heard about the importance of top management support for a successful change project.  Top management support is great, but even more important on a process change projects is the support of the supervisors over the process.  They are the individuals who will help you to understand the major pain points and they are the individuals who will sustain any improvements that are implemented. 

Often these individuals are not supportive of changes to the process.  They have a very parochial interest in the process – it is their job to ensure it is performing well.  They may view a project to change it as an attack on their ability or authority.  These individuals are often suspicious of the change and will actively work to undermine it.  So as you approach the change, don’t attack the old process; which will be seen as an attack on the supervisor of the process.  Rather acknowledge the benefit it has brought the business in the past and focus on how the changes will improve the performance for the new conditions that the process must operate under.

2. Fix the Customer’s Pain

Often this type of project is subject to scope creep.  There are many things that could be done to improve the process; but the project team is constrained by money and resources to only implement a few of the potential improvements.  Prioritize the potential changes in two ways.  First prioritize by the pain the process is causing to the customer of the process.  Fix the major pain points first.  When there are multiple ways to fix a pain point, then select the approach based upon the most important project constraint, either time or money.  

When you start to work on a process, the individuals in the process often have great ideas for improvement.  Many times these ideas may be an improvement from the perspective of those working in the process, but they may have no impact on the individuals or organizations that experience the result of the process.  Ensure you have addressed the customer’s pain, and then accommodate all of the other changes that you can.

3. Use Current Proven Technology

Many of the process changes today will involve some level of technology or system implementation.  A difficulty with technology for processes is that the technology changes rapidly.  About the time that you get all the bugs worked out of a new system, it is obsolete and must be replaced.  So to minimize that companies will sometimes leap to the new leading edge technology hoping that the time until obsolescence is further off.  But with this leading edge technology, there are still many elements that are not well characterized or that are discovered while doing the improvement project.  So what is the answer?  Try to use current technology that has been proven through multiple applications.

Now that is not to say you can’t use brand new technology.  However, when that is the case, the project is a higher risk project. Project estimates should be adjusted and budget and schedule reserves should be allocated to the project because there will be unexpected technical problems that must be resolved.

4. The Changed Process Must Be Simple

When creating changes to a process, you should always be looking to simplify any manual steps or personal interactions with the process.  Simple processes will run faster and with higher quality.  The principle is known as Poka Yoke, or mistake-proofing.  It is not the same as “dumbing – down” the process.  I am not suggesting that you curtail any of the performance standards or options, but rather, that you examine each step and determine if there is another way to accomplish that activity that does not require manual interactions, or that makes it easier to accomplish that step correctly.

An approach I have often used is to determine what a “standard normal” run of the process would look like.  I then do two things.  First create a screen early in the process to determine if this is a “standard normal” run, and then simplify and automate the main process for that “standard normal” condition.  The non-standard runs go through a more manual process, requiring more interactions and decisions.  This approach will accelerate and improve the quality for the “standard normal” runs.  And allow the process operators to focus on the unusual and difficult items without slowing the others.   

5. Test and Test Again

One of the biggest problems I have found with process improvement projects is the verification test run that goes flawlessly, followed by the implementation and operational runs that are a disaster.  A process improvement is not demonstrated just because you were able to do it once in a row.  A pilot run is needed.  In addition, the pilot run is susceptible to the Hawthorne Effect which means that the improvement is because everyone is watching while our best people do the work.  When the attention is gone and the average, below average, or new worker is involved in the process; the performance improvement is not to be found.

I suggest a pilot run of the process with sufficient quantity to establish “normal flow.”  If it is a customer interaction process, you should develop customer use cases that span the range of normal customer interaction.  If it uses technology, should test it with all potential operating systems or applications.  Finding the problem now while the project team is in place and can fix it is far better than finding the problems after the project is over and success has been celebrated..

Following these five tips will bias your process improvement project for success.  

Choosing the Best Project Management Methodology

Despite some claims to the contrary and the desires of senior leaders, there is no single “best” project management methodology for all situations.  At its core, project management is a process of creativity and change.  Whether it is developing a new product, building a new facility, upgrading an existing process/system, or planning your summer vacation; it is changing the existing state of things into a new and better state.  And this is why there is no one “best” methodology.  The existing state could be stable or in crisis, the new state could be clear or ambiguous, there are varying levels of constraints on time and resources, and there are varying levels of complexity of the project results and required activities. 

A project management methodology brings order into this environment.  It clarifies activities and decisions.  It sets expectations and identifies problems and issues.  A project management methodology enables proactive management rather than reactive fire-fighting as the future state is created.  But the wrong project management methodology can make things worse.  It can create confusion, frustration, delays, overruns and ultimately project failure.

There seems to be hundreds of gurus and experts touting their project management methodology as the best.  In reviewing these, there are three categories of project management methodology that emerge.  Each of these has strengths and weaknesses.  Each of these is appropriate for some types of projects and not others.  Each of these has many variations as they are uniquely applied to different projects, different industries and in different organizations.  The three are sequential/waterfall, adaptive/concurrent, and agile/scrum.

Sequential/Waterfall

This is the approach most often associated with traditional project management.  In this approach, the project starts with a clear and specific set of requirements.  A detailed project plan is created where each organization or individual is assigned a specific task that is to be done at a set time and for a set amount of resources.  As one project task completes, the results are handed to the next individual or organization in the planned sequence. 

This approach relies on the development of a detailed project plan.  The classic project management tools such as a Work Breakdown Structure (WBS), Gantt Chart, Critical Path Analysis, Responsibility Matrix, and Earned Value Analysis are ideally suited for this type of project.  These tools are used to optimize the project during the planning phase in order to meet the requirements within the best overall time or cost.

This approach is well suited for those projects where the requirements are known and stable.  It provides order and predictability to project activities.  However, it is not very flexible.  In an unstable environment or when the requirements are only general in nature and not specific.  The project manager either cannot form a plan or they must make many assumptions, some of which are sure to be wrong, in forming the plan.  Changes to the plan with this approach are often time-consuming and expensive, so this approach should not be used with a highly dynamic environment.

Adaptive/Concurrent

This is the approach that is often used with complex projects.  In this approach, a cross-functional or multi-disciplinary team manages the project through a series of phases.  As the project starts, the team is considering requirements and options to decide a framework for the project result.  The team reaches a decision and they start on the next phase.  The project progresses from phase to phase with all disciplines participating in the work concurrently and then agreeing on the project decision before moving to the next phase.  The project adapts as the team is able to use the results and conclusions from one phase to influence the activities and decisions of the later phases. 

This approach relies on a highly collaborative project team.  Rather than a detailed prescriptive project plan, the team uses key milestone decisions to guide the project activities.  The work is often iterative in nature as each of the team members builds on the solution from the preceding phase.  These projects are often managed by a series of checklists for each milestone decision point.  Project management tools that help to managed complexity such as the Network Diagram, Responsibility Matrix, and Risk Register are particularly useful with this approach.

This approach is well suited for those projects where the requirements are general in nature and the details must be determined during the course of the project.  In addition, this approach works well when cross-functional decisions are required to reach an optimal project result.  However, this approach requires a high level of interactive participatory project management.  The detailed plan is continually changing which requires a high level of project integration activities.  This approach is not appropriate for organizations that do not work well in a collaborative dynamic environment.    

   

Agile/Scrum

The agile methodologies came onto the scene in 2001.  Several agile methodologies were created for software development.  The Scrum approach has become the most widely adopted and is now used in many settings beyond software development.  This approach has provided structure to an age-old practice of putting a dedicated team on an urgent business problem to resolve it – the crisis project.  In this approach a dedicated team is assigned for a short duration to work on focused and prioritized set of requirements, known as a sprint.  The team does as much as it can in the specified time and delivers whatever it completes.  Requirements not completed within the time period are either dropped or transferred to a new project.  On larger projects, a series of sprints may be used.

This approach relies on dedicated self-organizing team to work collaboratively to complete as much as they can in a short time.  The classic project management tools are not used.  Instead, the team relies on a prioritized list of requirements and two visual control charts, a Scrum Board and a Burndown Chart to track progress. 

This approach is ideal for relatively small projects where time is critical and the scope can be flexible.  The project duration can be shortened by an order of magnitude, but it is essential that the team be fully dedicated and fully empowered to do the project work. In a highly regulated environment with externally specified requirements and extensive documentation, the benefits of this approach or lost.  Also, when the project team needs to be very large, this approach is inappropriate.

So to choose the best approach, consider your situation – both the project and the organization.  You may find the need to modify one of these a little, or even use a hybrid where one approach is used for a portion of the project and another for the remainder.