Software Project Blog

As a Project Manager, you need to manage people, money, suppliers, equipment—the list is never ending. The trick is to be focused. Set yourself 5 personal goals to achieve. If you can meet these simple goals for each project, then you will achieve total success. So read on, to learn…

The 5 Goals of a Project Manager

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these 5 goals for every project you manage.

Goal 1: To finish on time

This is the oldest but trickiest goal in the book. It’s the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.

Goal 2: To finish under budget

To make sure that your project costs don’t spiral, you need to set a project budget at the start to compare against. Include in this budget, all of the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under budget.

Goal 3: To meet the requirements

The goal here is to meet the requirements that were set for the project at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.

Goal 4: To keep customers happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. “Keep it real” by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can’t deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.

Goal 5: To ensure a happy team

If you can do all of this with a happy team, then you’ll be more than willing to do it all again for the next project. And that’s how your staff will feel also. Staff satisfaction is critical to your project’s success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The 5 goals you need to set yourself for every project.

Of course, you should always work smart to achieve these goals more easily.

Jason Westland has 15 years experience in the project management industry. From his experience he has created software to help speed up the management process. If you would like to find out more information about Jason’s online project management software visit ProjectManager.com.

It’s not always possible to know (or choose even if you did know) the skills and experience of everyone on a project team.

Sure, we may know the technical skills required (especially on a software application development project), but that is only part of the story when getting a team to work productively.

I guess we all will have heard of the “forming, storming, norming, performing, mourning” metaphor.

But in case you haven’t or can’t recall:

Forming – the team comes together and may well not know each other at all, people are usually initially polite and sound each other out, though forming impressions of each other very quickly

Storming – the next stage of project life – the team members start to ‘test’ each other, exert their influence, jockey for position (perhaps), argue, disagree, and push each other’s boundaries.

‘Norming’ – relationships normalise, initial impressions of each other have been reinforced or painfully changed through the storming phase and people react to each other in a more learned (about each other) way. The ‘johari’ quadrants have been expanded and realigned.

Performing – not all teams hit this stage, but when they do it’s usually from mutual respect and the team members recognise and play to key strengths of individuals whilst also compensating for each other’s perceived and real weaknesses.

Mourning – probably only a stage that is hit by a team that achieves the ‘performing’ phase. Team members lament the break-up of the project (the team really) because it was a supportive, rewarding and usually successful work-time. Even when many years have past the team members will recall ‘that project’ (that team) as being one of the best working experiences of their life.

Once past a few projects it is fairly obvious that this is forming, norming … process is exactly what happens each time a new project commences with people who have not worked together at all, or for a while, in a project team environment.

The team membership make-up directly contributes to how long and how intense each of these stages within a project lasts (or even if the latter stages ever occur).

And that can directly affect the success or otherwise of the projects goals.

At one extreme the project will just fall apart (despite you being a fantastic project manager!). At the other, the project will be a sublime positive experience that resides in all of the team member’s psyche for years.

The latter experience really makes projects fly and yes; you will yearn for these halcyon days in later projects that have poorly gelling team members.

So is there anything to watch out for? You may not always (if ever?) get the sublime experience of the emergence of a perfect team for the project/job in hand (I have a few times – am I just lucky?), but what can we try and influence to enable the chances that this will happen?

Firstly let us get the technical aspects out of the way. I assume from now that you can and have secured the correct blend of technical skills and experience required to carry out the specialised IT work. See, that was easy!

Yes I know in practice this can be as difficult to achieve as anything else, but it is reasonably obvious as we gain more detail and granularity of plans and solutions downstream as to what IT skills and experience is required, so I will just take this as a given.

So let’s get to the real successful project triangle…

People are complex. IT people often have egos ranging from the size of small planets to the size of the universe.

So, here is our first ‘gotcha’!

You have to be able to control people with massive egos. Especially those who have an ego that eclipses yours (is that possible?) If you can’t or won’t, then you must not have these people on the team. If you have no choice, then make sure you only have a few of these types relative to the team size.

The problem is that (usually but not always) there is a direct relationship between a massive ego and massive talent/success (albeit this might be in a narrow IT discipline that many people would not even have heard of).

Therefore first thing on our checklist is “ego-power” – it is the nuclear aspect of project teams – it can light the way for centuries or destroy all in its path. If you can’t control it, don’t use it. It really is that simple a rule. How honest you are about this to yourself is another factor though .

People are communication engines. IT people often and regularly misfire in this regard.

Our second gotcha has more difficult nuances to master.

The “N squared minus N divided by 2” rule (you know this one too right?) becomes all the more difficult to keep oiled if one of the nodes becomes asynchronous.

What am I talking about? Well the above is a self-illustrated example. Some IT people really find it difficult to construct meaningful verbal or written communication (but notwithstanding that, can often code programs faster than light) and others get so far entrenched in ‘consultant speak’ they obscure the real meaning of any communication.

Again it’s one extreme to the other, the middle way is needed. Too many AIs (Articulate Incompetents) or too may ICs (yes – Inarticulate Competents) and the team has a risk of meandering off course. ACs are what you need.

People like people. Mostly.

And finally, there are some people who just cannot perform as part of a team. Be brave don’t use them, specialist skills or not. It’s not worth the aggravation to you, the team and therefore the project.

The ECT project triangle…

It would be (relatively) easy to create a team based within the framework above if you had the required knowledge about potential team members (include yourself in the team – try a bit of self-analysis if your ego permits ) before the project kicks off.

And could choose team members at will.

But rarely is that the case. So mostly we just have to juggle, adapt and control within the real project iron triangle – the Ego/Competency/Team Player (ECT) triangle.