Aside from Agile, the most commonly used form of project planning in my experience is the standard waterfall model.  Each stage of the project follows in sequence – as one completes, the next commences.

Having worked in operations for most of my life, along with the odd sojourn into the project management space, it’s safe to say that it appears almost impossible to operate a linear strategy to project management beyond the very high level work package structures.

At least this is certainly the case when you are reliant on operational resources to participate in projects as most organisations are.

On paper, within a work package, an operational resource might be mapped in the plan to do their “bit” in the following form;

 But in reality, an operational person is usually working that more closely resembles;

• Plan for the day:  “Project time for the day as agreed with my manager”

• Reality of the day: “It’s breaking, we need  you now, you’ll just have to leave the project work til later.

Expected time on project work: 8 hours. Actual time on project work: 3.5 hours.

Result : Stressed out operational person, delayed project plan, frustrated P.M.

This is not through any fault of the engineer.

• The fault lies with the operational manager for over-estimating the available time to that engineer

or

• The project manager who pushed the operational manager so hard to give an estimate that fitted the timelines of the project.

Operational work effort is business as usual for an operational team  and not project work. In order for a resource to be given the correct amount of time required,  realistic availability needs to be put forward to the project manager.

If the timelines available do not work for the project then backfill needs to be found for the operational resource in question and this needs to be factored into the project costs. Ignoring the issue will end up simply causing problems for the project during implementation.

By organising operational resources correctly within the context of a project timeline, you can get closer to a linear delivery.  Just don’t look to closely at the operational resources day though – that’ll never resemble linear!

Photo: Raiderslight

When initiating any project or change, getting an understanding of the impact of that project or change is vital. Of course, you’ll know the intented impact of the project through the project business case.

Project impacts – considering the non-direct effects

Sometimes the obvious impacts are addressed, but peripheral impacts are over-looked.

• The impacts on the operations of areas of your business not directly linked to the project delivery.
• The impacts on your support teams (usually IT). Have their needs been considered in the project?
• The impacts on data security and integrity.
• The impacts on your customers.
• The impacts on understanding the operations of your business and business reporting.

When defining a business case, the non-direct impacts do need to be as carefully assessed as the impacts to the direct recipients of that project. Without understanding these project impacts, their may be negative side-effects of project implementation for your business;

• Increased costs of operation.
• Operational inefficiencies within the teams.
• Quality assurance concerns.

Effective project managers and project management methodologies will ensure that all impacts of a project implementation will be considered. The right questions will be asked to ensure that all possible project impacts are considered as part of the overall project plan and scope.

• All teams considersations will be factored in, not just those directly impacted by the project.
• Operational impacts will be assessed and changes to work practices initiated as part of the proejct implementation.
• Management reporting requirements will be included.

In some instances, the impacts of a project on wider areas may well negate the positives of the business case that was put forward in the first place to initiate that project.

While it may well help one area of the business, the implementation of that project may impact another area in such a costly manner that the project should be at worst cancelled, at best – re-assessed to include the impacts on the previously in-considered areas.

So when you are implementing a project in your business, make sure to cover off those silent “non-impacted” areas – you just never know when they may come back to haunt you!

Photo: Likeablerodent

Project management methodology – guaranteed project success?

Project management methodologies are highly useful tools with which to learn how to develop and deliver projects. The intention behind theme is to give the project manager a structure against which the project can be delivered.

However, there is a danger in my view and experience.

The danger that is the methodology can be rigidly adhered too to the detriment of the project or that the wrong methodology is applied to the delivery of a project.

Different organisations have different types of project. Project methodologies from one organisation may not necessarily appropriate for the project delivery methodology of another.

A project manager applying a waterfall based project approach in one organisastion may find that an Agile approach is required in another. The former project methodology simply doesn’t work and when attempted causes the projects to fail or run into difficulties.

Traits of a successful project manager.

The underlying principles of effective project management are independant of the methodology learned i.e. they form the basis against which a methodology is applied;

1. Ability for a project manager to communicate effectively at all levels.
2. Ability for a project manager to understand the importance of budgeting.
3. Ability for a project manager to understand how to manage risk and mitigate against same.
4. Ability for a project manager to work as part of a team and to understand that a project is reliant on successful team work.
5. Ability for a project manager to maintain the “big picture” view even when dealing with minutuae during the project delivery.
6. Ability for a project manager to deliver to time, quality, scope and budget.

A successful project manager will be able to do the above irrespective of the methodology applied. The methodology can then be learned for a particular organisation and applied appropriately.

If the fundamentals required for a successful project manager are not in place, the methodology will simply create a student of process which if applied incorrectly will not deliver the desired outputs.

What are your thoughts?

Can a project manager be successful simply by following a project management methodology?

Photo: Hyperbob

In my experience, the majority of people are starters. These people are often very enthusiastic at the start of the project but appear to lose interest as the project progresses. It’s not their fault, that’s the starter mentality. Finishers are those with great attention to detail and those who gain great satisfaction from completing tasks and scratching them off their list.

I regularly play 5-a-side football with friends. By simply looking at how people play a game of football, you can usually determine if they are a starter or a finisher.

Starters are those, sometimes flamboyant players, who like only to attack. If the game does not go their way, they lose interest and often stop running. These people rarely defend.

Finishers defend. They always know the “real” score and play to the death whether they are winning or losing. In order to win a game, you don’t need as many finishers as starters, but you definitely need some.

So, next time you are putting a project or football team together, be sure to pick finishers as well as starters if you want your project to succeed.

I myself am a finisher. Are you a starter or a finisher?

The main objective of the project manager is to deliver the project on time and on budget. However that’s not all when it comes to project success criteria.

In addition to above conditions, the project manager needs also to work closely with the customer to ensure that all the project deliverables have met the customer expectations. Defining the correct success criteria is key to any project and business.

By definition, a project is a temporary endeavour with a specific result or objective. If your project has no end in sight and/or no clear scope, then while what you are doing may be important, it is not a project. As a result you will have a hard time showing your team that they’re being successful or even progressing.

The Duke Nukem Forever project is a perfect example how a project without a defined scope or schedule can go really sour.
In order to determine if your project is a success, before you begin, it is important to agree on a short list of success criteria with all parties involved.

Examples of success criteria:

• Total project cost does not exceed X% of the initial budget.
• The actual delivery schedule is within X percent of the initial deadline.
• All high-priority functionality defined in the requirements specification is delivered in the first release.
• The estimated number of residual defects does not exceed X per function point.
• All unauthorized network intrusions are intercepted, prevented, logged, and reported.
• The mean time to failure under specified load conditions is at least X hours.
• The average installation time of the product is less than X minutes, with Y% of installations being error-free and requiring no support call.
• At least X% of software components were reused from previous applications.
• Pre-release development rework does not exceed ten percent of total development effort.

The best mechanism for open communication for a Project Manager is the Project Status meeting. The objective of these meetings is to highlight any issues as soon as possible and allow everyone to get on with their work. However, in practise, this is rarely the case. It is the Project Managers responsibility to ensure that these meetings are a success.

For those of you unlucky enough to have to attended a poorly run daily project status meeting, I am sure you are well aware of the many downfalls that are repeated throughout both IT and Non-IT Projects.

1. DO make it Routine

• Project Status Meetings should be typically held in the same location and at the same time each day
• Ideally the daily meetings are held in the morning as they help set the context for the coming day’s work

2. DON’T Schedule Meetings at Lunch Time or after 5pm

• Attendees will not be happy that you decided to use their lunch break or delay their dinner reservations for a Project Status Meeting
• An un-happy attendee will not be a productive attendee

3. DO Schedule Meetings at least 24 hours in Advance and Circulate an agenda in advance

• If there is no agenda, don’t have a meeting
• Even if the agenda is just to have a quick status update, that would suffice
• Having an agenda helps the participants prepare appropriately and anticipate the kind of information they might need to produce

4. DO Ensure that All Key Stake Holders can Attend

• If key points are being discussed and the decision maker is not there, it will only frustrate those that did attend

5. DO Set Ground Rules

• Laptops closed. Phones off or on silent. You’re either at the meeting or you’re not at the meeting, and few things are more distracting or disruptive than the guy who is banging away at a key board or typing a text every five minutes
• Let all attendees know that the meeting will be over much quicker if you have everyone’s full attention
• No mini-meetings within the meeting (i.e., no separate side-discussions during the meeting)
• Only the chair can interrupt when someone is speaking
• No bringing up unrelated topics
• Use only English (or whatever the language common to all participants) during meetings.

6. DON’T Drag the Meeting out Longer than is Necessary

• There is nothing wrong with a 5 minute meeting. Don’t feel the need to justify the meeting by prolonging it with non-agenda items
• The stand-up meeting has been proven to be an effective means of reducing meeting times

7. DO Take Notes

• Accurate minutes should be take throughout the meeting (by either the Project Manager or an appointed attendee)
• Take note of attendance
• A digital camera can help greatly in capturing anything on the whiteboard
• These notes can be used to summarize the Project Status Meeting at the end

8. DON’T get Side-Tracked

• All attendees have given there time to attend. Don’t waste it
• The daily meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised should be taken offline

9. DO Start and Finish on time

• There is nothing more frustrating than people turning up 15 minutes after the scheduled start time and the meeting running over by 30 minutes
• Consistently start and finish on time. This will gain respect from all attendees
• Provide structure and be firm about respecting everyone’s time

10. DO Summarize

• Be sure to use a few minutes at the end to review any major action items that were generated in the meeting
• The Project Manager should email the list of resolved and new action items to all the participants ASAP

As a Project Manager, do you have any other tips?

An often overlooked discussion at the start of a project, is to identify and define the roles and responsibilities of each team member. When projects go wrong, people frequently revert to playing the blame game…

”That’s not my job!” or “Isn’t Jack supposed to in charge of that?”

Too many Project Managers assume everyone understand their role. By clearly identifying who is on and not on the team, and assigning responsibilities, you immediately create a level of commitment and understanding amongst all involved.

In smaller teams often a meeting will suffice, however in larger organizations it may be necessary to develop a roles and responsibilities chart.

Does every one on your project knows what their job is?

I’m a PMP certified  project manager.

I’m a Microsoft Exchange certified engineer.

I hold a first class honours degree in management studies.

Certifications and degrees along with all other educational accreditations are great and education is the cornerstone against we can build our businesses and recruit talented people.

But..

An accredication does not a project manager, engineer, general manager make.

You can be certified up to your eyeballs, but unless you can apply that certification to practical use – its’ not worth the paper it’s written on.

You can talk the language but you need to be able to understand the impact of your learning in the environment you are operating in.

I have worked with a number of people, all of whom have an accreditation or first class degree applicable to their role, who were absolutely incapable of performing the role assigned to them.

They knew process or the technology or the theory, but the practicalities of performing in the day to day hub-bub of operational necessity was totally lost on them.

The theory suddenly didn’t apply to the business they were operating in.

“It’s not supposed to work like this!” was an expression I heard on numerous occasions and trying to explain the “real world” vs. the “theoretical world” was like pulling teeth.

I have of course worked with people who knew exactly how to apply their educational brilliance to the work place and they were all, without exception, super stars.

They were capable enough to know that the “real world” throws curve balls at you daily and were able to deal with it.

The “real world” is about people first and processes/technologies second.

The ability to work with people is instrumental in being able to deliver successfully.

What are your thoughts?

Photo: Dennis Wong

Project managers and business owners use a multitude of tools and resources to track and monitor projects.

Everything from the traditional pen and paper to the growing popularity of online project management tools.

We’re always interested to see who is using what on a day to day basis, so take the poll and let’s see what results we get!