• 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.

The post Agile project management appeared first on Project Management.

An interesting situation developed when we started discussing what constitutes a project.  I asked the students for examples of the types of projects they deployed as part of their work, so I could tailor my stories. The examples were varied of course, as many initiatives can be considered a project. Kumar indicated that sometimes he needed to develop fixes for software bugs; Justine said that sometimes she had stations to install or replace in her manufacturing line.  Ann mentioned she needed to plan Cable TV installations for her technicians.

I tried to understand Ann’s project constraints a bit better. Were the installations for new construction? For a group of existing customers? She seemed confused by the attention. The difficulty finally dawned on me when I asked what constituted the beginning and the end for her projects. She answered: “The first and the last day of the month”.

With a bit more discussion we realized that it was a misnomer to call her role a ‘project manager’, as her responsibility was an operation, not a project. Although she planned and assigned technicians and equipment for a whole month the effort never ended, it never ended. Similar to ‘payroll’ for example. She was astonished that neither she nor her management had realized this before. Her job planning, yes, but it never ended, which projects must.

Why is the differentiation important? Because one would optimize efforts that have a distinct beginning and end (projects) in a totally different way from efforts which are continuous and sustain the organization (operations). Everything from staffing to funding would be done considering different priorities and goals. Although Ann stayed in the class, I saw her on the last day signing on to a ‘logistics’ course.

The post Project or Operation? appeared first on Project Management.

A good friend recently was asked to go to Shenzhen to manage a project for his company’s Chinese business partner. As any good international traveler would do, my friend Fareed did as much research as possible before going to China. He read plenty of books on Chinese culture and customs; he got a Chinese cookbook; he even rented Chinese movies in Mandarin (with subtitles in English of course).

All this research yielded the following picture: the Chinese are a hard-working, collectivistic society. They are quite accepting of people in power and are highly contextual (which means that they take their cues from the situation more readily than from what is written).

I saw Fareed after his trip and asked him how the trip, and the project, had gone. “Great” he said “but instead of highly collectivistic I found everyone in China to be highly individualistic”. Based on his research, he had gone expecting people to act based on what was best for their group. Yet, everyone from the local builder, developer, driver, even the secretary took initiative and performed tasks depending on what was best for them, not necessarily their company. That came as a surprise.

We chatted about it at some length and finally arrived at the following conclusions, which we will apply to our future projects: (1) although a highly collectivistic culture in the past, given recent economic and other liberalization, Chinese culture may be changing from highly to moderately collectivistic. Maybe some day they will become an individualistic culture, much like the American or the Australian. And (2) whatever ideas you may have about another culture, even when based on research or experience, be ready to toss them out the window, as cultures are alive and constantly changing.

The post A Project With China appeared first on Project Management.

“Why is this so long, what’s in it?” I asked him. He answered that it was his RAID Log, which he used to run Status Meetings. He wanted to be certain not to miss anything, so he was careful to include every item related to the project and classify it as R (risk); A (action); I (issue) or D (dependency) in this giant spreadsheet. As the first section was ‘Risks’ they were certainly addressed. So most of the discussion in his weekly status meeting was about events that had not even happened.

To be sure, used appropriately, a ‘RAID’ log is a great tool to help Project Managers keep projects on track. It lists, in one easily accessible place, almost any present or future turn of events that could impact their project. A few difficulties can arise though, which diminish the usefulness of a RAID log.

Frequency
In an average project, risks may not need review each week, but in a high-risk project the risk log may need to be reviewed more often even than action items. Each project has a different makeup, which should dictate the frequency with which each category in a RAID log needs to be considered.

Importance
Four categories (R,A,I,D) can generate many items. That is why in each category there should be a way to prioritize which the team, in fact, follows. This means that high priority issues or actions can be discussed in the status review meeting, whereas low priority items can be pursued by the project manager after the meeting, and as time permits.

Management Approach
Finally, the items in each of these categories require a different follow-up approach. For example: ‘Issues’ are problems. Small or large, they are discrepancies or disagreements which have taken place within the project and must be resolved. They may require conflict handling, negotiations or management involvement. On the other hand, ‘Risks’ are events which may or may not occur. Arriving at risk mitigation requires brainstorming alternative approaches, yes, but may never even have to be deployed.

For these reasons, think carefully about keeping one RAID log, or keeping separate Risk, Issue, Action and Dependency logs to be monitored at different times.

The post To RAID or not to RAID appeared first on Project Management.

Certified Associate in Project Management (CAPM®) and Project Management Professional (PMP®).

If you’re a European reader, then you are more likely to be familiar with PRINCE2® and its 2 qualifications: Foundation and Practitioner.

Until June 2014, if you were a qualified PMP, then you would still need to pass the PRINCE2 Foundation exam before sitting the Practitioner exam. That requirement has now been relaxed according to the PRINCE2 certification body – AXELOS. Providing you are a current PMP (i.e. your status has not lapsed) then you will be able to sit the PRINCE2 Practitioner exam without having passed the PRINCE2 Foundation exam.

This is good news for PMPs who wish to expand their professional qualifications. Many people often see PRINCE2 and PMP (or more specifically the PMBOK® Guide, on which the PMP exam is based) as 2 alternative approaches to managing projects. I think this is a simplistic view as I will now explain.

The PMBOK Guide is a detailed description of a number of knowledge areas, processes and techniques which a project manager should really be familiar with when managing projects. It’s based upon project management best practices. The PMBOK explains what the project manager is responsible for on a project, and only to a minor degree talks about the responsibilities of the project sponsor.

If I were to sum up the PMBOK I would say it’s good at describing core project management knowledge and how to do things – e.g. how to perform critical path analysis or how to manage stakeholders – but is not so good at explaining simply what needs to be done, when and by whom.

PRINCE2 on the other hand is very good at clearly explaining the steps required at each point in a project, what needs to be done and who is responsible. PRINCE2 also goes much further than the PMBOK in detailing the responsibilities of all roles within the project management team (of which PRINCE2 defines 9 distinct roles). PRINCE2 however is weak when describing how to do things – for example it only describes 2 techniques.

Whilst often, aspiring and practising project managers often ask “which qualification should I take – PMP or PRINCE2?” I personally think this is a false dichotomy.

As I have tried to explain here, the PMBOK describes “the knowledge and the how”, whilst PRINCE2 describes “the what, the when and the who”. Any tradesperson cannot do their job properly without a full range of tools in his/her toolbox. The same is true of project management. Use both the PMBOK and PRINCE2. They complement each perfectly and they will help to make you a better project manager in the end.

For those PMPs reading this, perhaps now is a good time for you to consider expanding your project management knowledge by gaining your PRINCE2 Practitioner certification as well. Oh and don’t forget, to keep your PMP status up to date you need to show you have obtained the relevant PDU’s. What better way of achieving this than to attend a PRINCE2 course which can help you to fill in those missing gaps which the PMBOK left out?

PRINCE2® is a registered mark of AXELOS Limited. PMI®, CAPM® and PMBOK® Guide are registered trademarks of the Project Management Institute, Inc.

The post Project management certification just got easier appeared first on Project Management.

“The volumes and volumes of reporting and paper my PMO demands have become completely unwieldy ”… “What’s worse is that, after all the hours the different measurements, trackers, logs and reports take nobody looks at them, much less management!”  It appears Line of Business managers were now asking for reports additional to PMO reporting so they would be relevant, thereby increasing time demands on project managers.

It was not always like this.  When the PMO first came into being in that company, about a decade ago, it was well received and immediately successful.  Projects back then were just “stuff that needed doing”.  No standards, no templates, no regular reports.  Some project managers were more skillful than others, and they got better promotions.  But with the PMO, all projects began to be more successful.  Common reporting began.  Tracking progress began.  Unsuccessful projects were reshaped or cancelled.  A few years later unfortunately, PMO demands had snowballed , and many new rules for projects had questionable value.

Last year, for example, their PMO had issued the mandate that the time units for all projects had to be “days”.  Any project artifacts not in “days”, had to be edited and re-published using “days”.  Every estimate, every schedule, going back a year.  The reason was that the PMO felt it was pivotal to link all project schedules such that they could be rolled-up into one grand, “master schedule” for the whole company. My friend was aghast.  “Hundreds of [obviously unpaid] hours required of project managers to retrofit project documentation, and for what?” …  “Show me a single management decision that was made or changed from rolling up these collective schedules.  Does any manager even look at these rolled-up figures…?  She had a point.

So it is critical that management in our PMOs remain vigilant.  It is important that they stay relevant and engaged, so they don’t take the PMO in questionable directions. PMOs are a natural source of change in the organization.  If they cannot effectively introduce important changes, who will?  Here are a few recommendations for PMO management:

Identify And Rank Problem Areas

The PMO and its management should be able to articulate at any given point which are the company’s pain points they are solving.  What areas in their projects need improvement?  What is their ranking?  Is it profitability?  Is it resource utilization?  Then introduce new changes slowly, careful of correlating them with expected business benefits everyone (or at least senior management) considers strategic .

Seek Feedback From Experienced PMs

More managers could take advantage of the knowledge their more experienced resources have.  Who better to evaluate what works or does not work in projects than the people who have been deploying them for customers, for years?  All too often a good solution has been crafted by those in the front lines, but the problem remains unresolved because no one has asked those with first-hand knowledge what a good approach might be.

Retire Tools That Do Not Work

Finally, PMO management needs to be courageous enough to alter, or retire altogether, tools that are not producing expected business benefits.  Maybe the tools take too long to deploy.   Maybe they place additional hours of burden on project managers.  Implementing a project is tricky enough, so let us try to not give project managers, additionally, the PMO Blues.

The post The PMO Blues appeared first on Project Management.

In Waterfall projects there often are Status Reports which list the tasks in the current work packages and their status. The tasks come from an agreed, project-wide Work Breakdown Structure.

In an Agile Scrum, there is no previously broken down, far-reaching Work Breakdown Structure.  The team works from a ‘Product Backlog’, or prioritized list of functionality, which they have agreed with the product owner.  They then commit to deliver a certain portion of functionality during a 30-day Sprint.  Since the team organizes itself on how to deliver this functionality, and checkpoints daily on their progress and problems, the content of the work is very fluid.  They cannot commit in advance to finishing this or that task in this or that timeframe.  All they can commit is to deliver finished, working functions by the end of the 30 days.  At the end of the Sprint, a “Sprint Review” takes place.  So how could one issue weekly status reports, when Scrum offers no Work Breakdown Structure?  Just the daily checkpoints and the review of the Scrum at the end of the 30 days?

I am sure there are a variety of creative workarounds Project Managers (ie, Scrum Masters) are using. One of the more successful approaches I have seen entails using the ‘Product Backlog’ as the basis for a status report.  The Scrum Master can list the requirements or functionality in the Product Backlog as if they were work packages.  Then, they discuss how close to completion these various functionality items are.  Sometimes there will be a requirement in the Product Backlog which is not easy to visualize as a work item, such as “User Friendly Interface”.  In this case, verbs can be added to give the stakeholders an idea of what the project team is doing, such as “Test Interface with 4 different types of users”.  This ‘hybrid reporting’ will then allow the Scrum Master to perform another very important responsibility:  protect their project team from distractions and interruptions during the Sprint.

The post Agile Reporting From Waterfalls appeared first on Project Management.

All this plastic got me thinking about green project management and whether environmental concerns can be better integrated into mainstream project management. Although to give them credit, the local government here does take recycling waste very seriously. There are bins everywhere – one for plastic, one for paper, one for tin cans, another for glass, and one for the stuff which cannot be recycled. But aren’t we doing things the wrong way round? Rather than producing a whole lot of plastic and then collecting and recycling it, wouldn’t it be better if we didn’t produce as much in the first place?

After thinking this through, I think it’s time to add another aspect to a project’s performance – sustainability and the project’s contribution to it. If we can set targets for sustainability on our projects, we can work towards a more secure future on this planet for our children. For example, when you procure resources on your project, do know if they come from a sustainable source? The paper which you use in your office – does it come from a managed plantation, or from trees felled in a tropical rainforest?

Hang on a minute I hear you say. The shareholders and executives in my company only care about the bottom line and therefore it’s my duty to buy resources in an efficient way. If buying resources from sustainable sources costs more, then it’s not going to happen. This is certainly true. In a commercial organization, the project needs to show a return on investment, but in non-commercial projects this isn’t necessarily the case.

It’s also true that we have probably always sourced things based upon cost, so doing things which are more costly just isn’t going to happen. I think this is where education plays a part.

Project Managers who are concerned about sustainability can now gain knowledge and accreditation in green project management. A quick Google of sustainable project management also revealed this book which looks like a really interesting read. It’s on my list of books to read in the coming months.

By Project Managers gaining more knowledge of sustainability in relation to project management, they can begin to educate corporate executives why setting sustainability targets on projects can only be a good thing.

The post Green project management appeared first on Project Management.

We are reviewing the contract, deliverables, deadlines etc. on a given section of the work, when I notice the monetary amount in that section does not seem very large. Diplomatically, I suggest we do a “Pareto Analysis”, and prioritize the preparation of the larger items. Pareto Analysis (also known as “the 80/20 rule”), refers to the analysis of the Italian economist Vilfredo Pareto, where he observed that 80% of land in Italy was owned by 20% of the population. More recently, it has been applied to many more uses: what 20% of the effort would contribute to 80% of the improvement; which 20% of customers bring 80% of your business.

“Oh yes” said my customer, “let’s do the Pareto thing”. So instead of a small work item, we analyze and document an item which -by itself- is more than half of the total amount in dispute.

Pareto analysis is one of the first tools the project manager should reach for, suggesting to us which 20% (ie, small amount) , if addressed, would bring us the 80% benefit (ie, large amount). It can help us prioritize change requests. It can help us organize the resolution of problem log items. If funding has shrunk, it suggests which work to keep in scope; which to de-scope. Even in Agile Scrums, Pareto Analysis can bring clarity to the product owner about which high priority work to deploy in the next Sprint. It can be applied to large items -such as which budgets to analyze first-  and to small items  -which phone calls to return first-.  So do use it extensively.

As to my customer’s arbitration: they lost 2 items and the contractor won 2 items. The contractor’s items were about 25% of the amount in dispute, my customer’s items were 75% of the amount. The contractor just did not present a very compelling argument. He must have run out of time. For my customer, the Pareto thing paid off handsomely.

The post The Pareto Thing appeared first on Project Management.

I’m writing this post from Tokyo, a city I have visited many times previously – both for work and for leisure. It’s been rather cold since arriving, but nothing which a boy from the north of England cannot endure.

So, what’s this got to do with project management? Well, quite a bit actually, if we consider the move (which I made with my wife who is Japanese) as a project.

Planning

Like all projects it required a plan. We (I should say my wife) made a very detailed plan, which started months in advance, and got more detailed the nearer to got to the moving date. There were several milestones along the way – putting our house on the rental market for example.

Changes

Things changed unexpectedly which meant that we had to take some decisions and re-plan accordingly – for example when the nice tenants we had found for our house wanted to move in 3 weeks earlier than we wanted.

Risks

There were risks to be considered – for example, what if our 2 lovely Chihuahuas weren’t allowed on the plane, or worse, were refused entry when we faced quarantine at Tokyo’s airport? Governments tend to like paperwork at the best of times, but I was totally unprepared for the amount of paperwork demanded by these two rabies-free island nations.

Execution

So, the plan evolved – injections, visas, tickets, moving, packing, selling the car – each one ticked off as they got completed, each one getting us closer to the final day.

My wife did an astonishingly good job of planning everything – even down to having futons and duvets, cutlery and crockery delivered within 2 hours of our moving into the Tokyo house the day after we arrived. Two hours later, the fibre-optic cable was installed for our internet connection. My wife has never been on a project management training course, but for her, the planning of all the different steps involved follows a certain inherent logic, just like it would on any other project.

48 hours prior to departure we had to have various paperwork completed by our vets in the UK. The day before flying this had been faxed off to the Japanese quarantine people who had promised to check it before we arrived.

Murphy’s Law (if something can go wrong it will)

On the morning of our departure their reply landed in our inbox. “Don’t forget to bring the original rabies antibody test certificates with you – otherwise your pets may be refused entry and may be sent back to their country of origin”. We looked at each other in horror. Of all the things which we had thought about and had planned for, we realized this was the one thing which we had overlooked. In fact we didn’t have the originals – they were at the vets in London.

We immediately phoned the vets. Luckily they still had them and we could pick them up on our way to the airport. So, we made a 2 hour detour to get the certificates, but this was well within the slack which we had allowed in the plan to get to the airport.

So, we arrived at the airport, after driving through yet another of the UK’s winter storms and went to check-in. The attendant took one look at the dogs in their crates and said we couldn’t take them. We couldn’t believe it. We had double-checked when we booked the flight that the pets could be carried in the cabin. We argued and when he realized that they were bound for the cabin we were OK to check-in with both dogs.

One huge sigh of relief and a walk through security later, we were able to board. Eleven hours on a flight with no toilet or food or water is not much fun for a small dog. Yet despite a few passengers being startled by the occasional bark, their first flight was thankfully pretty good.

Lessons

So, what lessons can we take away from this? Well, for one, plan your project. Had we not planned in detail, there would have been a lot more surprises along the way.

Make sure you analyse all risks beforehand and ensure you have a plan to deal with them. We had tried to reduce most risks, for example by researching in detail the requirements of the Japanese quarantine and the UK pet export regulations. But there was always the chance that we might be refused entry.

Lastly, be prepared to change your plan, when things come up unexpectedly.

I’m sure that you have had similar experiences when managing projects not just at work, but in your personal life too. Did an awareness of project management methods help you as much as it helped me?

The post My own moving country project appeared first on Project Management.