ProjectPro.org.uk

It may sound obvious to most but Project Management and Line Management are different roles and each brings specific skills, working together in an effective organisation.

Line managers have the ongoing responsibility for the admin, personal development, job satisfaction and well-being of those under their charge.

Project Managers focus is on achieving the objectives of a project. He/she has responsibilities the Line Manager may not (such as managing Risk, Scope, and the Customer).

The temporary nature of projects means that good quality line management is vital to ensure staff have the continuity and stability from which to contribute effectively to their projects. A company run by Project Managers would be a pretty scary place.

In terms of Project Control Processes, I’ve come to consider Risks and Issues as intrinsically linked, despite that many sources and courses teach these seperately.

Here’s the logic: An Issue is a Risk with a 100% likelyhood.

Issues are problems that need to be managed, in the same way as a risk once a trigger point has been reached.

The procedures for distinct risk registers and issue logs, means that Project managers can at best incur greater administration or at worst they can lose the holistic view that a combined view would give.

Ask yourself how many status meetings have you been to where the majority of the session is spent fire-fighting the issues and zipping through the risk log right at the end – or worst still, suggesting that be looked-at at the next meeting.

If the scoring system were adequately calculated it could be that some HUGE risks should merit higher attention than minor issues and should in truth be prioritised higher up any single list.

Agile seems to be becoming the default approach to projects. However, here are a few of my own observations to those considering this methodology for their next project.

Agile was born out of a realisation that projects often delivered results that were obsolete or had little relevance to the business by go-live day. This was mostly because:

1. The requirements changed drastically from the start of the project; or
2. The business wasn’t able to describe the requirements at the start of the project.

Agile wasn’t designed to be the most economical approach and it inherently has features that mean it often costs more overall than waterfall.

The financial benefits of an Agile approach are attractive because of techniques associated with it (i.e. Prototyping, constant user interaction, prioritising requirements), but these are for the most part applicable to traditional waterfall projects as well. I would be interested to see metrics comparing waterfall versus agile where these specific techniques have been applied to both.

On the other hand Timeboxing, as a means of attaining flexibility, is a technique that sets Agile apart from the convential waterfall.

Sponsors and PMs should bear in mind that the core methodology is inherently inefficient, in that:

• Applying iterations means that code is revisited and may be modified several times (with multiple rounds of testing).
• Non-functional Protoypes are an overhead, if not used in the end solution.
• Greater user interaction means that customers must devote more time to the development process.
• And from a technical point-of-view code that has been rehashed several times can result in poorer performance.

But, on the assumption that a solution that is not ‘fit for purpose’ post implementation is a waste of time and money, what Agile was designed to offer is confidence.

• Confidence in timescales and budget – later iterations can potentially be dropped if either runs out.
• Confidence in suitability – that the solution will have undergone frequent review in the course of the project, rather than fixed from the start.

Back in the 1990’s DSDM (Dynamic Systems Development Methodology) included a suitability test, to establish whether the project was a credible candidate for it. From what I have read XP and “Scrum” don’t have this step. So the Project Manager must perform this assessment outside of the methodology, and I suspect that many projects are managed in an Agile way, without due consideration of whether it’s the right tool for the job.

So, rather than follow the herd, take a moment; weigh it up and conduct your next project in the most appropriate way. Don’t simply assume that Agile is always best.