Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile

5 things to do when projects go wrong


5-things-to-do-when-projects-go-wrongAnyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.

1. Show leadership

An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.

2. Avoid temptation to simply throw more resource

A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.

3. Avoid sugar coating

There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.

4. Undertake review

Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.

5. Follow up

Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.

Do you have any rules for managing troubled projects? I’d be very keen to hear.

Prototyping: storyboarding, paper prototyping

Reblogged from tisquirrel:

Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post

The three main techniques for rapid prototyping are: storyboarding, paper prototyping, digital prototypes.

Read more… 857 more words

What responsibility do outsourcing organisations bear?


Savar_Jeans_BloodI have taken a bit of time mulling over this post. I was born in Bangladesh, but have been an expat for most of my life. As I looked on in horror at the calamitous scenes from the garment factory collapse in Savar and the outpouring of grief from various quarters, I could not help but think if the likes of Walt Disney, Diesel, GAP and Walmart are in some ways not partly responsible for it. What of my own profession where I have managed projects where I have been both the supplier and customer in outsourcing situations … how much effort did I really put in to ascertain conditions?

Let us look at the motivations of outsourcing. There are usually one of two reasons to outsource. First an almost without fail the reason is cheaper supply cost. A secondary reason I have sometimes dealt with is rapid mobilisation, which in New Zealand context is difficult to do simply because of the size of the market. It is probably unfair to even try and compare projects I delivered as the sub-contractor, as the working conditions here are in no way comparable to the scenario in Savar. However, I did utilise sub-contractors in India for some projects. Did I really try and explore if conditions are great there? How are they able to mobilise so quickly. What happens after the project is complete? Not really, I just assumed that someone in the executive had done that due diligence. Never occurred to me to check.

Can this lax attitude be excused? Companies spend a lot of time selecting suppliers with the correct skill set, that can deliver on time, have the correct quality control measures. Should they not be expected to provide equal oversight to the working conditions? This becomes quite a thorny issue. They are engaging the supplier for a set of services or products. They can legitimately expect working conditions should be responsibility of local administration. Many of these suppliers serve many masters. Who should then be responsible for conditions.

Even if these companies are willing to take on the burden of ensuring good working conditions, can they really achieve that? The building that collapsed housed five garment factories and had an A category safety certificate from the Fire Service, even though the entire construction has been documented to  be illegal. Local officials have obviously been on the take for some time to allow the construction and then issuing of false safety certificates. No reasonable person can lay the blame on the outsourcing companies for such failures.

Pope Francis called the working conditions as modern slave labour. There is an element of truth in there. However, one must be careful not to judge conditions through western standards only. $38 buys a lot more in Bangladesh than it does anywhere else. This industry also employs 4 million workers, same as the entire population of New Zealand, 80% of them female. It has given a large section of the community a voice and self reliance that never existed before. Those protesting in front of these companies to stop doing business in Bangladesh must remember that would hurt these people more than the owners.

The world runs on influence. What these companies have over many of the suppliers is leverage. They use this every day to drive down their procurement costs. They should use the same to better the working conditions. As these companies have found out, there is a reputation risk even if there is no legal obligations. Treat the working conditions in the supplier environment as a risk that needs to be managed like any.

Where there is a will, there is a way. The world came together to end trade of conflict diamonds and apartheid in South Africa. Surely some social responsibility is not too much to ask.

Image Credit: http://www.sifascorner.com

Why LinkedIn dumped HTML5 & went native for its mobile apps

Reblogged from VentureBeat:

Click to visit the original post

LinkedIn has just launched the latest versions of its mobile apps, and in a stunning reversal, it's gone from mobile web-based apps back to fully native.

Less than a year ago, the company was touting its iPad app as fully mobile-web based, with just one screen, the homescreen, running natively. Now, all that's gone, as is some of the optimism about the current capabilities of the mobile web.

Read more… 594 more words

Not strictly project management, but has implications if you're delivering to an IT audience. HTML5 vs Native is a constant debate.  

How do I construct the perfect project estimate?


I went to the New Zealand PRINCE2 User Group Wellington Chapter meeting on Tuesday night. As usual the calibre of speakers were excellent. Conrad McDonnell and Barry Calvert spoke on various aspects of estimation. It was quite interesting perspective, one from an IT/vendor angle and another a construction angle.

Importance of a shared vision is not something that I had previously connected to a good estimate. Conrad was quite persuasive on his argument on the need to understand the vision as a pre-requisite in this respect. It is amazing how many projects I have worked on that has started with not all stakeholders having clarity on what what success looks like. Here I do not mean success delivering to a set of agreed deliverables, but something that would advance a measurable business outcome. I can see his point of view. He gave the example of the NASA programme to land on the moon and the vision that John F. Kennedy outlined in his speech.

Perfect Project Estimate

He talked about the vision in the context of a progressive estimate with increasing level of certainty. The key to any good vision is to not assume it is understood by everyone. It must be communicated with a feedback loop. Before the programme or project begins, high level planning must occur. The key to estimation at this stage is to understand your levels of uncertainty and recording your risks. It is key to remember there will always be different levels of certainty at all stages in your project or programme. In an IT context, you may have near certainty about cost of hardware, but little clarity on required design effort. As you execute, you must continually plan, execute and re-plan. Expect to take a few detours on your journey. This is where clarity of vision will help.

Barry talked from a construction point of view and had an analogy of a pancake. It only has four ingredients – flour, eggs, baking powder and milk. Flour is the one that determines the size – what is required, by whom, when – the basic facts. That sets your base criteria for estimate. Eggs are what sets your environmental conditions and is complementary to your flour – what environment is it being delivered, the intended use, slope of the land, other influencers. Baking powder is what gives it the fluff – the nice to haves – types of finishing, flooring, fittings etc. Milk is what gives it the consistency – this is your repeatable methodology and constant refinement of it. Even though he gave the example from a different industry, I like the principle of it. I have a feeling I will re-use it.

One thing that was clear from both speakers was the folly of trying to go back to the customer with a number too early in the piece. Whatever you do, customers forever remember the first number or date.

There is nothing called a perfect estimate. You can only ever get reasonably good at it.

Follow

Get every new post delivered to your Inbox.

Join 523 other followers

%d bloggers like this: