Author: Kevin Lonergan

Posted on

Agile project management

A corporate woman giving a presentation on agile methodology to a group of persons

Right now there is no single more popular topic in (especially in software) projects than Agile. Before I describe what it is, here are the most common misinterpretation of what it is not:

  • it is not a methodology – it is a set of values and principles;
  • it is not a project management ‘method’ – it is a product development method that can be combined with other practices to cover the entire scope of planning and delivering projects.

You can take an agile approach to the management of anything (as far as possible) and what that should mean is that you are following as many of the principles of Agile as possible. Does that mean that 87 storey buildings are going to be delivered and accepted in an incremental manner? I think not.

Agile addresses a number of challenges which many would argue are ignored too often by projects in the past. However, it is a mistake to say that traditional methods fail to do what Agile does, the truth more lies more in the interpretation and implementation of traditional methods by project teams in the past. For example, there is nothing in Waterfall that says you can’t plan and deliver the project in a highly collaborative way; it’s just that people chose not to.

So what does Agile try and achieve?

Agile accepts a number of things, for example:

1. Priorities change
2. People find it very hard to envisage and sometimes communicate physical requirements, especially towards the font-end of projects and even more especially all in one phase.

It tries to have a development process that recognises, accommodates, allows for these and provides a more productive environment for requirements to emerge and be confirmed before actual code is developed, on a just-in-time basis.

It also encourages very short development cycles, so that the review (by users) of product is continual throughout the development process. When it works well, this can be an excellent way of producing product and reviewing it (almost) in real-time as it is developed. It’s the very opposite of a big bang approach and should reduce the size of issues to make them far more manageable. By the time you get to the end of the final iteration, there should be no major surprises. The development should be driven by the priorities of the business and therefore functionality of greatest importance should be at the core of the deliverable.

One other aspect is also attempted and that is to delay decisions until they have to be made. This can have advantages but takes a very skilled team. All development activity carries uncertainty so if uncertainty manifests itself around late decisions this could cause real issues and delays. This principle needs to be applied with great skill and care.

Agile can enable some really good things but there are some ‘Agilists’ who spread some very dangerous messages. For example: Agile does not do deadlines; projects begin with a product backlog; there is no accountability in Agile teams; Agile does not do (need) project management (on larger projects there are usually many things outside the software development – clearly these will all need to be managed too).

Agile is fairly simple to understand in principle – much harder to do (well) in practice.

Posted on

more stuff on the “common sense” debate

there was a debate for years around whether Project Management is an art or a science.

The truth is that neither are correct on their own – it is both.

Successful project managers (with a track record of more than one project) typically employ the science stuff (core PM concepts), sometimes religiously.

They also harbor a good deal of the “art” side as well. One example of the art would be the harder to define competencies or even what some people call personal qualities that good PMs have, for example judgement. You cannot be a successful project manager (of anything non-trivial) without very good judgement.

Something that is (sadly) not found in all of us.

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

following previous post: is “PM” just common sense

Well here’s my view. If project management (or delivering projects successfully, on a more often than not basis) were purely common sense, then the evidence to do with project delivery performance would tell a completely different story. For example, a UK report by the Royal Society of Engineering a few years ago quoted some frightening numbers on the cost overruns (in £) that is wasted each year in the UK on IT projects alone. There are many other examples from other industries to back this up this assertion.

It is an interesting thought as well that in many fields of business (engaged in projects) there are often professionals in abundance (i.e. degree or better qualified staff) working on those projects, and often they still produce disappointing results, i.e. unsuccessful, sometimes spectacularly so. You would suppose that this group could master what some say is just “common sense”, if this is true?

The reasons for poor project delivery can sometimes be complex, including:

– lack of real pressure (in some industries) for improved delivery performance
– lack of corporate capability relating to business level Governance of key projects
– lack of accountability of key individuals across the project for delivery performance
– issues of communication, poorly applied practices etc

The list could go on and on, and does depending partly on Geography and industry sector.

The best examples of project management practice are: a) relevant to the industry, technology (or domain) being managed, b) focused on the issues that are key to the sponsor or business; and c) are routinely employed by project teams as key disciplines which they get obvious value from; they do not consign them to the “we haven’t had time to do that yet” pile. In other words key professionals understand the relationship and difference between core project work and project management. In the history of the industrial era to date, evidence does not seem to support that this “common sense” prevails yet in buckets in most people in most organisations?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

is it all just “common sense” ?

From time to time in my business life, someone will ask, or sometimes say that project management is ‘common sense’, meaning it is just common sense.

Often they are making a statement along the lines of ‘what’s all the fuss about this PM stuff, it’s all just common sense isn’t it’?

Well, my question is, of course, is it just common sense or as some would say, a whole lot more more?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

Scrum versus Waterfall?

Many methods have emerged over the years that are hailed as the greatest and latest way to deliver a project. A good example would be the “scrum” method for delivering IT projects. The scrum concept is implemented in a number of ways, one of which could be to pick groups of requirements which are delivered in ‘packets’ as the project progresses through sequential ‘scrums’.

Scrum is therefore one of many approaches that might be adopted as a strategy for delivering a project, and in some respects it could be quite different to a waterfall type of a approach.

However, there is one thing that remains as a constant regardless of approach – all projects require the fundamentals of project management to be in place and to be practiced. In addition, any method that divorces the project team from the overall goals of a project is going to be a project that runs a severe risk of not delivering the full need.

It could easily be argued, that the fundamentals of project management (relative to distinct project types) should not change regardless of implementation or delivery strategy. That would be a useful dicusssion?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

Procurement and projects – best and worst practice?

The following is definitely not at the “best” end.

I recently had to respond to a bid for major customer – in the customer ITT the usual procurement rules were laid down. The ITT had been written in English; by someone who’s native tongue was not. The document was full of inconsistencies, incomplete or vague and conflicting statements.

In the procurement rules in the ITT, it stated that: “no meetings or verbal discussions would take place with any of the bidders” – all communication would done in writing, and it got worse, in one single pass. In other words, no clarification on the customer’s response to bidders questions would be entertained, and from this, the bidders were expected to present binding fixed price bids.

Sadly, in the world of procurement, this is not an isolated case.

Many projects rely completely on procurement, but too often the project team’s decisions or needs are overruled by the procurement process or function – and the end result? The project has to try and fix the issues that this leaves behind or generates – and sometimes they can’t be fixed.

Surely there has to be a better way?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

Organisation and projects:

There are many elements in the environment of a project, and ‘organisation’ is one of the most important. Organisational decisions can encompass wide-ranging aspects, such as partnerships, key supplier and sub-contracting relationships and responsibilities within a project – and that’s the key word: “responsibilities”.

Making responsibilities clear at the practical working level, perhaps phase by phase, is one of the most important tasks a project team will do. The converse is that if we don’t make responsibilities clear, the downstream impact of this will all too often be measured in cost, schedule and technical terms – sometimes this alone leads to substantial impacts on a project’s success and delivery goals.

So, if this is the case, why is it that so many project teams roll along without spending much effort or paying attention to this question – it seems such a fundamental thing to do, but corporate and individual behaviour does not always support this?

What do you think and what are your experiences on your projects?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

Being a project manager means

there will be times when you will not be the most popular person in the room ……

Much of the lot of the project manager is concerned with dealing with issues; that may mean bringing attention to issues, their source, impact and resolution to the table for the project team, sponsors and executives to resolve. In these circumstances, project mangers need to be: open; ruthlessly objective; focused; and visionary. Not every individual would relish this responsibility, for example, in a recent conversation with wanna-be project managers, many practical examples of issues that PMs may face were discussed – not everyone in the room was happy about being responsible for managing their resolution and what this would entail in real life.

Testing issues such as this should be an important element of selecting project managers as well as defining their responsibilities.

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

Being a PM doesn’t mean I have to chase people on tasks, does it?

As with many walks of life, there are many views on project management. The following short discussion demonstrates brilliantly the differing views of people relating to the task of project management and the responsbilities of a project manager.

When having met an organisation recently I was talking to a few project managers, and one of them said to me: “being a Project Manager doesn’t mean I have to chase people on their tasks does it” (to provide some context, this was a relatively small firm with small project teams – less than 6 key people in each project team).

It’s an interesting question as on this alone you get completely different behaviours (and processes) among Project Managers, and resulting from this alone you can get very different results from projects.

Let us know your thoughts on this question?

—————————

For more resources, see the Library topic Project Management.

—————————

Posted on

PM Certification – does it make a difference?

Certification programmes in vocational qualifications have exploded in the past 10 years or so, and the project management world is no different.

In the US, the Project Management Institute’s “PMP” qualification probably leads to way. In the UK we have a similar qualifications from our own “Association of Project Management”, for example “APMP” – we also have Prince2 qualifications, which is primarily the UK Government’s project management methodology.

But here’s my question: do you think that having a certificated project manager makes a real difference to the project or otherwise?

Let us know your thoughts?

—————————

For more resources, see the Library topic Project Management.

—————————