First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Friday, 22 May 2015

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase I keep as a prompt. In this post I will look at the human side of teams. It isn't an easy subject because as with most things "human" there is no exact science to get to where you ideally want to end up - with a high performing project team. So I accept that while these are my views, some may disagree or have different approaches.
The "P" in PM is as much about People Management as it is Project Management

Project Teams - delivering more than the sum of the parts

We all know a high performing project team when we see one. Everyone contributing, looking out for and supporting colleagues, going the "extra mile" to achieve milestones. Basically producing more than the sum of the parts. But how do we get to this state?

From what I have observed in the IT world at least, project teams are typically brought together for the Project with typically a mixture of in-house resources (including some seconded to the project from other roles) augmented by individual contractors and third party suppliers (who may have a small or large part in the overall project). 

A new team brought together doesn't normally have that sense of TEAM and so the Project Manager needs to try and help engender a "team ethic". A number of things can contribute to getting to a real team and events outside work can contribute. Sometimes the team needs to go through a Form, Storm, Norm, Perform process to get to the high performing state.


Good communication with the team will encourage good communications back and assist in creating a team spirit. Also take a look at the post on Project Communications. So:
  1. Keep the team updated on what the plan is (hopefully several people were involved in creating), progress against plan, your view on RAIDs etc. The approach can vary on project team size and culture but certainly I prefer to publish a weekly Status Report which is available to everybody to read. However, assume that many will not read so use Project or Programme Town hall meetings to do updates and answer team wide queries
  2. General communications should typically be augmented by weekly meetings with key individuals / groups within the Project Organisation to discuss progress, discuss & gather new RAIDs and next steps
  3. On a one to one basis, I always aim to be as honest as I can in communications, calling out good things, saying when I don't believe a good job is being done.

Recognise that there are different Personality types

You need to appreciate that there will be different personality types in your team (and your stakeholders too!). The formal way of assessing is via psychometric testing such as Myers Briggs where each person is mapped to 16 different personality types. It is unlikely that this is going to be undertaken on most Project teams but as a People Manager you and other team leaders should have an awareness that people are different, the clues to their personality types and how this affects the approach to interact with them and in addition, how they are likely to respond. 

To take one concrete example, someone in a senior position is most likely to be a personality type such as ENTJ and will want summary information, not wallow in detail so consider this when communicating.

So try and assess / understand the personality types in your team, within your Stakeholders and don't forget yourself! Then interact accordingly.

Be Genuine!

My personal approach to building relationships is to be a "genuine" person. I always try and be honest with people (whether praising or criticising) , value people's input, don't be serious all the time so have a laugh and a joke, balance listening and talking etc and take some time to learn about what people are up to outside work. Don't forget in the heat of battle to say thank you and well done when appropriate!

In terms of being Genuine, don't think you can "fake" these interactions because people will quickly see through that. If you aren't the type of personality to naturally interact then try and develop these skills but some argue a leopard cannot change his spots. However my belief is that you can change your personality a little over time or maybe just self-manage a little better knowing your own characteristics and how others see you.

The bottom line in interactions with team-mates is to build trust with people over time so that when the pressure is on they are committed to achieving and going the extra mile as necessary.

Feelings are important

I would say the best training course I ever went on was with the Leadership Trust which had a number of cleverly designed and challenging exercises involving stressful leadership situation(s). I still remember that after each exercise there would be a de-brief and one of the stock questions was "how did that make you feel?". We should be mindful of how we are feeling and assess how team mates are feeling. How people are feeling affects how they perform tasks and links into the topic of Motivation


Motivation is the inner force which drives our attitudes and behaviour. It can make the difference between someone with the same skills who on one side delivers little, clock watches, browses the internet et al and someone who is head down delivering useful things to help deliver the project, goes the extra mile etc. I am no expert in psychology so here are a few points which I keep in mind:
  • look for the "win-win" deal, project win and personal win. Sell the experience that delivering on the project will mean for the person CV wise
  • involve the team in planning (or if an individual has not been involved explain the resulting plan) so the person understands what part they play in achieving the overall objective
  • establishing a team ethic can help motivation e.g. delivering for team mates, not wanted to let the team down etc
  • broadly I agree that money isn't a long term motivator unless it is a big incentive linked to success. Serious lack of money (well below norms for role) can be a de-motivator however!
  • if you observe a demotivated person, don't ignore, have a quiet discussion, try and establish why and if it is fixable, try and resolve 
  • a bad apple can spoil the barrel. So a really de-motivated person you can't turn should be removed from the project team before infecting others

Adopt Different leadership styles

You (and your team managers) should adapt your leadership styles to apply in different situations are shown below.
Project Manager Leadership Styles

  • Delegate - If a member of the team has good skills & experience and a motivation to get things done then you can just delegate tasks with little supervision or support. Agree the scope and objective of the task, a target date and let them fly. You may not even ask for regular updates because you trust them to get the job done or alert you to any problems i.e. working on an exception basis
  • Coach - If your team member is very willing but lacks some skills and experience of the task at hand then you can use a coaching style where you agree the scope, objective and target date for a task but you have more monitoring and control in place with regular checkpoints. The conversations should be two-way and you should be a bit of a sounding board and advise as appropriate but often it is more about giving confidence to the person. So it is an investment and hopefully the person can do more thinking for themselves eventually and you can move towards a delegation style. If you or your team manager(s) don't have the knowledge or bandwidth to coach another approach is to buddy someone alongside a senior member of the team
  • Support - You assess that your team member has the skills and experience but lacks the drive to get things done. There could be a number of reasons for this such as basic laziness, a personality which is easily distracted etc. You have regular short checkpoints for good monitoring & control giving praise when the person is on track and a size 9 boot when they are not! 
  • Direct - if the team member lacks skills, experience and motivation start worrying! But while you worry, you need to get the task done so this needs the most frequent monitoring & control and basically you direct to say "do this", "now do this" etc. If things improve, hopefully you can move more to a coaching style with more two way conversation as this is best for the individual and you.
In the above give consideration to work package principles I went through in a previous post.

Some Proverbs for you to remember

As always, there are a few Proverbs which are worth remembering:

Nothing is impossible for the person who doesn't have to do it
  • Nothing is impossible for the person who doesn't have to do it
  • You can con a sucker into committing to an impossible deadline but cannot con him into meeting it
  • Good leaders do not take on all the work themselves; neither do they take all of the credit

Friday, 8 May 2015

Check a few things before joining the Agile bandwagon

Agile Application Development methodologies have been around since the early 90s with different detailed methodologies coming in and out of vogue. Whatever Agile methodology is adopted, the proposed benefits are attractive - faster and cheaper delivery, higher probability of users getting what they want etc. Before jumping on the bandwagon and abandoning waterfall, I recommend working through a viability check-list to ensure you have the right conditions to be successful (note - only joking about muddy scrums!).

Application Development Methodologies - Waterfall or Agile?

First some history

The waterfall model of system development has been around since the mid 70s. This approach adopts various phases (e.g. Analysis, Design, Construction, Testing, Implementation, Maintenance) which are deemed complete based on quality assured documents which allows entry into the next phase in the style of a water flowing over a waterfall! This basic approach was formalised even further in methodologies such as SSADM in the 80s. Waterfall has plenty of rigour but has some disadvantages
  • the cost of document production / validation  
  • users need to agree requirements and functional design quite early based around discussions and see a working system quite late on in the life-cycle. The risk is that they didn't get it quite right when they agreed these early documents.
  • the cost of change later on the lifecycle is high (pushing water back up the waterfall is never going to be easy!).
Alternative approaches started to be proposed, the first I am aware of was the Spiral model in the 80s. The "alternative movement" gathered more pace when James Martin introducing his book on the Rapid Application Development (RAD) methodology in 1991. When I really looking into these approaches the methodology in vogue was the Dynamic Systems Development Method (DSDM) which I first successfully utilised in projects during the late 1990s. Other Agile methodologies such as XP have sprung up and as I write this in 2015, the current UK Agile vogue is SCRUM

Agile methodology in generic terms

Agile utilises time boxed iterations rather than phases used in waterfall. Small teams work together (including representatives of business stakeholders) to develop the requirements of the iteration, develop the code and test the results with user involvement. The resulting working application (for requirements developed in the iteration) can be shown to stakeholders allowing fine-tuning of requirements while they are reasonable cheap to change. A number of iterations may occur before a system is ready to release into production usage.

Is my Organisation / Project suitable for Agile?

In producing this check-list I admit to being heavily influenced by DSDM but I believe they apply to Agile as a concept.
  1. Will the application under development have significant user interface requirements e.g. screens and reports? If true, this is point in favour of Agile. Conversely if the application doesn't have a significant user interface and is just a complex computation, a written specification will likely be better to develop and test against.
  2. Are the requirements unclear or likely to be subject to change during the life-cycle? (e.g. external influences such as government legislation being developed or simply the business users have difficulty articulating their requirements). If true, this is a big point in favour of Agile. 
  3. Can the application be sensibly delivered in increments? This is a core principle of Agile methodologies.
  4. Is there a clearly defined user community and can a representative of this group be actively involved in the team? If either of these questions is NO then there are dangers that incomplete requirements or wrong requirements may be captured in the Agile iterations
  5. Is the core team small enough? A team size of around 7 is often considered the maximum for Agile.
  6. Is the core team empowered to make decisions within each iteration? If the authority hasn't been delegated to the team driving the iteration, momentum will be lost and in a time-boxed iteration, little will be achieved.
  7. Is the core development team stable and dedicated appropriately during each time-boxed iteration? Saying that Fred is dedicated for 4 days and then he will be replaced with Harry for the rest of a 2 week time-box isn't going to be effective.
  8. Is the core development team co-located (ideally) and if not, are suitable tools available to aid collaboration (e.g. Trello rather than a white board). Agile uses less documentation and relies on excellent communication between team members so look for barriers. This includes the inter-personal skills of team members. In my experience look at the developers in particular, some really don't like to communicate and are more suited to working from a document!
  9. Skill and knowledge level of the core development team. Having a developer new to the technology who has just come off a training course or a user who has no domain knowledge of the business area affected isn't going to make the process work effectively.
  10. If external resources are involved, are the commercial arrangements suitably framed? The contracts must recognise that the system requirements may evolve with some backward movements to achieve the ultimate goals.


So go evaluate the check-list and if the responses are favourable, Agile can be a really effective development methodology to use with big benefits in terms of timescales and most importantly delivering something which really meets business needs. If not, I suggest that you stick with Waterfall. Although it seems plodding by comparison, the checks and balances of document quality processes and phase gates create the rigour for successful delivery even if there is the risk of costly change requests late in the life-cycle.

Twitter Delicious Facebook Digg Stumbleupon Favorites More