Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Project manager

5 things a tech lead can do that a Project Manager cannot

I was talking to a former colleague and reminiscing about some of the projects we had worked together. He is still in a technical role and enjoying it. I have long since moved into project management and have been enjoying that. As friends would banter, we started talking about how our different roles give us different flexibilities and constraints in projects. I really enjoyed the perspective and though I’d share the things that we thought a tech lead can get away with that a Project Manager cannot.

1. Do the work themselves

A wise man once said if you need a job done well, do it yourself. There is an element of truth in that. Sometimes it is more optimal to do the work than to explain what needs doing. If you are a technical lead you can easily do that yourself from time to time for expediency. A Project Manager cannot really do it. That is especially the case if they have less content knowledge.

2. Be blunt in feedback

There is a different code of interaction between technical people when they relate to each other and when they relate with others. In their own way they can afford to be quite open and challenge each other. This may not always manifest in a cohesive way, unless there is trust between the various personnel. Many times this is how they challenge each other and extend their own knowledge. Project Managers deal in more shades of grey. They meet people from many different stakeholder groups and bluntness is the last thing you want. You may take a client’s requirements to your technical team and how often have you heard the comment … “this is cr*p.” From a technical point of view this may be a very legitimate answer. However, the Project Manager needs to translate the reasons from a business point of view that would preclude it being an option. Both groups are trying to achieve the same outcome, but communication style is very different. Often getting the client to be flexible enough to think differently is where good Project Managers distinguish themselves.

3. Relaxed attire

Tech leads are usually in a position where any interaction with the customer is planned well ahead of schedule and most of the time they are not necessarily required to be customer facing. They can easily be in the office in the jeans and t shirt. A Project Manager on the other hand either needs to dress differently in most industries, or keep a separate set of clothes in the office and be prepared to change as soon as needed. Managing stakeholders and project teams is a less precise activity than managing technical work.

4. Chasing the Cool option

Tech leads can often go off on tangent to do things that interest them. These could be trying out new design patterns, pet technologies or even specific devices. There is always a good argument in favour of innovation or up-skilling that can justify those, within reason off course. Project Managers are required to be more outcomes driven. If something is not geared towards meeting an outcome desired by the stakeholders, there is little appetite for doing it.

5. Turning phone and email off

While this can not be done for long periods, tech leads can have periods of time where they can turn the phone and email off and lock themselves in a room in order to concentrate on particular technical challenges. A Project Manager will struggle to do that. Turning off the communication tap is the worst thing they can do. This is a sure way to send a project south. Certainly, a lot of the communication ends up being wasted effort. Any risks or issues you may be able to pick up through the communication channels that you can prevent before they get to unwieldy proportions outweigh that.

If you have read this far, you may think why would one want to move into project management from a technical role. In fact not all tech leads make for good project managers.  Not to worry, we had an equivalent list of things that a Project Manager can do that a tech lead will not be able to do. That is a post for another day.

If you have moved into project management from a technical role, I would be quite interested to hear your list.

Image Credit:

5 different types of Project Managers

I am preparing to deliver part of a day long project management workshop at a conference. As I was thinking through the content I wanted to cover and reading some references, the BBC was covering the US Presidential election and relative chances of Barack Obama and Mitt Romney. Inevitably, the religious angle came up. Funnily enough, I was thinking about how dogmatic some of us in the project management field are about the way we work. Religion and project management has some ironic parallel. I can categorize project managers and religious followers in the same 5 high level baskets. A bit of creative generalization on my part, but hold this thought.


The Ideologue

The fervent believer. In religious context, holding extreme view … my way or the high way. Everyone else is wrong and the wrath shall fall upon them. In project management sense, these are the Project Managers that catch a specific methodology and way of working and stick to it come hell or high water. They are not one to be shy on telling everyone whey they are correct in their ways and everyone else is wrong. They are not particularly interested in hearing any conflicting ideas and have no appetite for discussions. They already know it, no-one else gets it. Just like fundamentalists, there is not much you can influence with this type of project manager. You can only pray that you get a team that fits to their style.

The Zealot

A slightly considerate version of the ideologue. A firm believer nonetheless, who is willing to acknowledge contrary views exist, but considers his views the most appropriate and sniggers at all others. In a religious context, I relate this group to the clergy. In a project management sense, these are the ones that adopt a particular methodology really strongly. While accepting other schools of thought exist, they give little credence to the usefulness of those and look down upon others that do not hold similar views. This is probably a redeemable quality. You may one day be able to get them to accept an alternate point of view. In my experience most project managers fall in this category.

The Practitioner

This is a group that is more concerned about the practicalities, rather than a particular belief. From a religious context, I equate this group to the general followers of a religion. They are not concerned about all methodologies going around. While they may specialize in a particular methodology, they are not shy in adjusting it to the situation and if necessary borrowing from other methodologies to make it work. This would be the ideal project manager in my view. However, project managers being of strong wills and of a mind to control most things, it is hard to get to this space.

The Secular

This is a group that is not particularly concerned about methodologies. They are happy to go along with any methodology and let others get on with whatever they choose. From a religious context, I equate this group to the believers of sort that kind of understand the basics, but is not particularly worried about the customs of the religion. They may go to the church or the mosque every so often, but not feel guilty if they have not. From a project management sense, these are people that are yet to develop an attachment to a particular methodology. Usually these people are new to the field and looking for the correct guidance. They are the group that can be converted to the practitioners easily.

The Non-believer

This is the group that feels little or no need for methodologies. From a religious context you can equate this group as atheists. From a project management perspective this is highly dangerous, and possibly do not see the value in investing in this discipline. The only thing you can guarantee with this approach is inconsistency. Making it up from the seat of your pants is not as exciting from a strategic view as it is sometimes from a technical view. Unfortunately, I have seen a few too many IT projects that fall into this category.

This was my attempt to parallel religion and project management. Have I been too generous or critical of any particular group here?

No offense to any religion is intended.

Image Credit:


Expectation is reality

We hear about perception being reality in service management space. When you are dealing with projects, expectation become the be all and and end all. How your project is perceived is proportional to the level of expectation about the outcomes that you have built.

Expectation Management

In the project paradigm, cost is the easiest attribute to communicate. If the expectation in the business is that a particular deliverable will cost 100 hours and your team delivers it in 105, it will receive somewhat begrudging acceptance. 110 will get people thinking whether it was worth the effort. Conversely, if you had built the expectation that the cost would be 120 hours, then even if you spen 115, the business will consider it a great delivery.

This may sound non-sensical, but it is the truth. How does one go about building this expectation? Do you just inflate estimates to achieve this? You cannot necessarily do that. If you are a monopoly supplier like inhouse team, then you may be able to get away with consistently over estimating the effort. In a services business, there is competition for this work and you do not want to turn away business by being too conservative.

At the same time, you do not want to be forever undercutting your competition to get work. In that scenario, you are always left with the scraps to fight over. You are in it to make a profit. If my cost is going to be more than my fees, then it makes no sense to take the work on. This can be a difficult juggling act unless your sales and services teams work closely.

Expectation is not only some thing that you as a Project Manager end up managing from the customer side. What is a good project from a deliverables point of view, may not be a great financial success. If you are running a project on a time and materials basis and are accomplishing things much quicker than anticipated, you are in fact depriving yourself of income. How do you avoid that? I recommend undertaking additional testing and documentation to ensure higher quality.

If the same project is being delivered on a fixed fee basis then the drivers are different. Your motivation now is to ensure the minimum effort you can spend to have the outputs delivered. You can make good profit by being efficient. Yet, some customers will begrudge that. Your work may have saved the client 100 hours of pain and priced accordingly. But if you achieve that in 80, the client is upset with you being accused of taking them for a ride. Yet, the same customer conveniently forgets that you carried the risk on this and had the project taken 120 hours, you would have been forking out services for no fee. We want to have our cake, and eat it too.

Then here are always those projects, where the customers have a want that is far out of proportion of their cost appetite. Be wary of this. It is a very common occurrence. It may sound like a good idea at the inception of the project to sharpen your estimates to land the work. This can only lead to bad work. You are setting the project team up to having to cut corners. If you really have to discount, do so on the basis of rates. The work is what it is. There is no up-side to compromise on quality.

What makes things difficult is that there is no right or wrong answer. It totally depends on the environment.

Image Credit:

How do I influence to get the desired behaviour?

I attended a training by an industrial psychologist Keith McGregor covering topics on why people behave the way they do and how to use strategies to get the outcome that you desire. For the first few hours, I was thinking this is a total waste of time. By the end of the second day, I had changed my mind. While I am still not convinced about the entire content of what was presented, I did take away some strategies to help me get the outcomes I want from my project team members. Here is a quick summary of what I have taken away from the training.

Keith gave one example that stayed with me after the training. He was talking about a four year old child of his neighbour’s who constantly asked him questions about everything when he went to tend to the trees in his backyard. It got so annoying for him that he only used to go tend to the trees on Sunday mornings, when he knew the child’s parents would take him to Church. Here, a four year old child is dictating the behaviour of a trained psychologist. Now think of the opposite end of the spectrum. Many organisations have office admin workers who have to chase up after people to get the correct paperwork, so they can balance the ledger, or process the monthly payments, or reconcile the accounts. Most people have the tendency to look them as annoying. There is always someone in the organisation that is considerate to them. When the time comes for them to do something for the staff (i.e. order supplies), they will always remember those that help make their lives easier. If you paid attention, you’ll notice they always receive their supplies first, and do not have to ask for this. People consider other people that help them as their leaders at an emotional level and are usually pleased to return the favour.

A second reflection from the course was the concept of “feeding the monkeys.” The idea comes from an article published by William Oncken Jr and Donald Wass in Harvard Business Review in 1974. Here the monkey represents the next required action on a particular task. The project manager is responsible for planning, delegating, monitoring and controlling all aspects of projects, and the motivation of those involved, to achieve the project objectives within the agreed tolerances of time, cost, quality, scope and risks. Project Managers should not end up owning actions on deliverables of the specialist products produced by the projects. Project Managers must ensure that all communications end with the delivery team owning responsibility for the next action and actively remove tendencies to be told what to do. Otherwise tasks stall for the Project Manager to make a decision and project team sits waiting for it. Monkeys should be fed or shot (task cancelled), they should never be starved. Delegate tasks on projects and grow capability in the team. 

The project team members usually comprise of different personality traits. There are largely six different types of personalities and you need to temper your communication according to their dispositions. The example here was when a school child was asked what did you learn today the inevitable answer was … “nothing.” However, when the same child was asked “did you have fun today?” she could not be stopped. You can deliver the same message to different groups, with a minimal change in emphasis to get your point across. Remember, no one belongs to a single box. Observe people, find out what levers to pull.

The biggest impact a Project Manager can have is on how they respond to behaviour of the people that are working on their projects. There are only three possible responses to any behaviour. Behaviour can be rewarded, punished or ignored. When behaviour is ignored, by definition it is being extinguished. Expect the intensity of the behaviour to increase. Punishment is what will get the quickest results. However, if that is to be used to improve behaviour, it must be done where the self-esteem is not destroyed in the process. Done too often, it will cease to have any impact. Rewarding is the most sustainable response to encourage the behaviour you want. It is best to thank people, rather than praise. Praise does not allow someone to understand what is being appreciated and why. Always state the behaviour, the impact it hand and then thank. Instead of saying “you did a great job,” say “I understand you stayed back last night to help Amanda complete the release. It meant we managed to deliver the product on time. Thank you.”

As human beings our tendency is to always pay attention at the worst moments. There is maximum attention when the project is headed south. Little or no attention is paid when things are on track. We also spend most of our energy dealing with the problem children and tend to leave the well performing ones alone. This is a recipe for discontent. The biggest risk in projects is the good people will be disaffected and leave. Do not water the weeds while the plants wither away and die.

Content Acknowledgement: Keith McGregor.

Major Image Credit:

When projects go too well

As a Project Manager, I strive to ensure my projects go really well. Experience tells me that all projects will go through some difficult periods during its execution. Projects are inherently risky and not all risks, influences and impacts can be predicted in advance. That and years of experience delivering projects has made me weary about a project going too well.

Ignorance is bliss. However, when exposed the results are seldom pretty. There are many reasons why a project may appear to be going better than what is the reality. The project team may have a different world view than that of the customer. This is a very common scenario, especially in the old days of long waterfall software development projects. The advent of the Agile methodologies has come about through a desire to remove this expectation barrier through short iterations where the customer has the opportunity for feedback. That alone, however does not guarantee success.

Many times, it is much easier at the start of the project because the pressure of deadlines is not so immediate. A day’s delay here and there does not seem to pose a great danger. There seems plenty of opportunity to make up for any lost time. However, as the project progresses, this becomes less and less possible. Unless the project is planned with enormous slack, in my experience it is impossible. The student syndrome is well and truly entrenched in project teams. If someone is given more time than is needed for a particular task, they relax too much early on and only put the foot down when they think they are nearing the critical path.

In the context of a supplier delivering products of services to a customer, the early days of projects are much easier. All parties begin with the intention of getting to the end goal in a one team approach. However, the business pressures are different on the supplier and customer. Therefore, even with the best wishes, a one team approach is very difficult to sustain over a long period. Equally, when the discussion is about benefits and approaches, it is a much easier conversation to have. As soon as the conversations move towards billing for costs from the supplier side, or project assurance or performance measurement from the customer side, discussions are inevitably more difficult.

Work cultures and how individuals behave during uncertainty also play a major role in project success. Some people have the tendency to not ask for help and hope they will be able to persevere through any difficulty they are having. They consider asking for help as a sign of failure. This can lead to drastic consequences, despite well meaning people. Bringing to attention any risks or issues to late in the piece will guarantee it cannot be successfully navigated through. There is no substitute to knowing your people.

The biggest mistake I see made when projects go well early is project teams sometimes get too comfortable and stop doing the basics correctly – keeping tabs on scope, documenting decisions, communicating effectively, enforcing change control etc. People are by nature reluctant to rock a boat they consider is sailing well. If you always hear everything is going well do not be content. Do some project management by simply walking around and getting the pulse of the team. Having a good handle on whether status reports reflect reality is a must. If there are issues, it is much better to know them early.

Do not relax when projects start well. You are under less pressure and should take the opportunity to compile good project management artifacts. If things turn sour, these are what will help navigate a course.

Image Credit: The New Zealand Railways Magazine

%d bloggers like this: