technical lead and pm

Does a Technical Project Need a Technical Project Manager?

Many organizations believe that projects of a technical nature (IT, engineering, etc.) need a project manager with technical expertise.  The technical expert can manage the project since they obviously know what they are doing.  The problem with this is the assumption that a technical expert is both capable and willing to manage people, schedules, and budgets too.  This may be the case but often is not.  There is no doubt that a technical lead must oversee the design and construction of whatever is being built, but this is not the same as project management.  Having been a software developer for many years then managing software development projects, I know from experience that it is difficult to do both jobs well.

Here are some definitions that clarify these project roles.

Technical lead– This person designs the product whether it be a building, car, or software package.  This person’s primary job is to make sure the product will work as specified.  This may include technical discussions and guidance for other technical team members.  It may also include specifying how the product will be developed if there is not a standard methodology in place.

Project manager – This person works closely with the technical lead to create a project schedule, identify risks and issues, control changes, report status to management, track the budget and schedule, etc.  This person must also possess soft skills to facilitate team communication, mediate team member disputes, provide motivation, etc.

The project manager and technical lead must work together as partners in executing the project.  If the roles are clear and not overlapping, this works well.

It is very helpful if a project manager is familiar with the technical jargon and culture of the industry that the projects are executed in, but the PM does not have to be the technical expert and it usually works better if (s)he isn’t.

From Geek to Project Manager

Hi, my name is Bruce and I am a Geek.  I am also a Project Manager.  I started out as a Geek though.  When I use this term, I am talking about a technical professional that speaks in jargon and is good at what he or she does.  Being socially awkward is not a requirement.

When a technical professional becomes very good at their job they often want more influence in the organization.  They are often trusted by management to deliver results and believed to be able to influence others to do the same.  The Geek is then made a Project Manager.  This is often a difficult transition however.  I know this not only from my own experience, but also from watching other people go through it also.  Here are some of the problems that can occur and what you can do to avoid them.

  • Treating human resources like machine resources – People are driven by emotions, not a CPU clock.  Getting them to do something you want is not always as easy as it sounds.  Ignoring emotional drivers is not effective at getting things done.  The more the PM understands about why people behave the way they do, the more effective they are going to be.
  • Failing to delegate everything – If the PM does technical project work, they become much less effective because their focus changes to solving technical problems instead of team problems.  This article discusses this further.  It is hard to let go of the technical stuff, especially when someone less experienced is doing it instead.  It is okay to mentor, but being responsible for working technical project tasks is something that should be avoided.
  • Estimating tasks for team members – An experienced technical person can often make accurate estimates on how long it would take them to do a task.  It is sometimes difficult to get an estimate from a team member or to believe the estimate.  However, if the team member does not buy into the estimate, it is not accurate and they cannot be held to it.  It is just wishful thinking and not useful for creating a project budget or schedule.
  • Telling the team how to do everything – There is a difference between mentoring and micromanaging.  A technical expert has a lot of knowledge, but a PM must respect the skills and maturity of the team.  As a PM your job is to ask the team what needs to be done and then organize that and track it.  Telling them in detail how to do everything will result in the PM doing everything.
  • Imposing a technical solution on the team – Geeks can often arrive at a technical solution alone that will work faster than a team.   If the team did not have input to the solution then they are not as motivated to implement it.  A Geek that is now a PM should get input from the team on what the solution should be so the solution will get implemented with the team’s full energy.

Is there any advantage to having a former Geek become a Project Manager?  Of course!  Here are some of them:

  • Understanding what the Geeks on their team are saying – Geeks speak in jargon that must be translated by the PM into a status report that management understands.  A PM that speaks Geek and plain language will communicate more accurately than one that does not.
  • Intuitively knowing the risks with various technologies – Risk assessment must still be done with the team’s input but a PM that was a Geek can suggest things to get the team going on this.
  • Knowing what motivates other Geeks – Things motivate Geeks that do not motivate other people.  The opportunity to work with new technology, gadgets, peer recognition, etc.  A Geek PM will know about these from their own experience.
  • Expert authority – Geek team members will respect a PM that used to be a Geek like them because they know that the PM has “earned their battle scars” so to speak in the technology arena.  This is very useful to a PM because they do not usually have direct authority over these team members.

Geeks can make the transition to Project Manager if they avoid the pitfalls listed here.

Hidden reasons why things don’t get done

People are reluctant to report a lack of progress on a task even when they don’t have everything needed to do it.  The fear is that the truth about why they didn’t get it done will not be acceptable.  I know when team members that are late on tasks start avoiding me that this is probably their fear.  Most of the time the problem that they are having with getting it done is common and correctable once it is identified.  These are still hidden, so it may take some coaxing to identify them.

Here is a list of the most common hidden reasons why tasks do not get done and what to do about them:

  • Work is not well–defined – The resource is confused by the task description but does not want to look stupid.  This could be cause by any of the following:
    • The task needs to be decomposed further and the resource assigned to the original task will only be doing part of it.
    • The task is assigned to the wrong resource.
    • Requirements for a deliverable need more elaboration.
    • The task may not need to be done at all.  It is not applicable.
  • Don’t know how to do it – This is often the case in IT where the technology changes quickly.  I am not talking about incompetence here.  One cannot get a person with 3 years experience with a tool that only came out last month.  A resource does not want to look stupid, but they may be the best person available.  Training or allowing time for the learning curve is the way this is often resolved.  Assigning the task to someone else is another alternative
  • Don’t have everything needed – There is a previously unidentified dependency on something else.  This could be another task, a tool, equipment, or specifications.  Sometimes resources just need help identifying what they need.  Simply asking them what they need and then providing it usually resolves this.
  • Higher priority work – When resources are shared they are reluctant to tell you that some other project, customer, or work effort was more important than yours.  That may be the case however.  It is important not to take it personally and escalate within the organization if needed.  If the organization deems the other work more important, then you adjust the schedule accordingly.  If not, then the resource gets corrected about today’s priorities.
  • More complex than expected – This often happens in projects.  The resource did not realize the complexity until they started doing the work.  There were constraints that they did not realize existed.  Resources may be embarrassed to admit this because it makes them look like they don’t know what they are doing.  Getting a new estimate and revising the plan is the usual remedy.
  • More volume than expected – The work is well understood, but the volume of things to be worked on is much greater than expected.  This is so common it even happened to Bob the Builder. :) This could be a case of scope creep (see below) or just underestimating.
  • Scope creep – A stakeholder asks the resource to do more than planned or the resource gold-plates their work.  Quality standards will help with the latter and encouraging honest and open communication will prevent the former.
  • Technical issues – This is very common in IT projects because the technology being used is often not very mature.  Tracking these in an issues log until they are resolved is the technique used on most projects.  Publishing this issues log lets the team and all the stakeholders know what is being done about the problem.  This is not usually hidden if the team knows there is a process for dealing with it.

Being able to identify these help you deal with them in your current projects and being able to discuss them openly with your team helps them find ways to prevent them in the future.

Getting the Truth

All tasks are being completed when planned and within budget.  There are no issues, risks have all been mitigated, and the project team members love each other and work perfectly together.  How would you like to give that status for your projects every week?  If you did, would anyone believe it?

Real projects don’t go perfectly most of the time.  They have a few warts and sometimes are downright ugly.  Our job as Project Managers is to report the truth, whatever that is, to the world.  Getting that truth from the project team is sometimes difficult though.  What follows are some tips that will help you get to that truth.

  1. Don’t shoot the messenger – During the Operation Desert Storm (the first Gulf War), there were stories being reported by the media that Saddam Hussein would shoot his Generals if they didn’t perform well.  As a result he was often not told the truth about what was really going on.  This caused him to make a lot of bad decisions.  Verbally attacking project team members that do not tell us what we want to hear has the same effect on our projects.  If you have a customer, project sponsor, or boss that is like that you may be tempted to be less than candid in your status reporting.  Don’t go over to the dark side!
  2. Document issues – When a task does not go as planned it should be documented as an issue in an issues log.  The task could be late or over budget for a lot of different reasons.  It is important to document these in an objective way that identifies the problem and what is being done about it; but does not blame team members.   This issues log should be public to build or maintain a culture of transparency.
  3. Probe estimates – The estimates of time or cost that seem too good to be true probably are.  People are often very optimistic and do not account for risks when giving estimates.  Making mistakes and having to do rework is a daily reality in the workplace that is not always taken into account.  Reminding resources about this and asking them for more detail about the task being estimated and what they need to do it usually yields more realistic estimates.
  4. Ask for clarification until you get it – Sometimes people create confusion deliberately to hide their own failures.  This can be done with technical gibberish or just disorganized rambling.  When someone you are collecting status from does this, take the time to organize what they are saying and ask them to explain until you have enough information.  This requires some patience, but stick with it until you know the truth.  There is probably something there that you need to know.

Project Management tips and techniques