Project Management in Practice

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

Tag Archives: United States

Are conference attendances useful in delivering better projects?

I was at an industry conference at San Diego last week. Aside from the stark difference basking in 26°C, compared to the 6°C that I left behind in Wellington, what struck me most was how projects face the same challenges the world over. Having spoken to my counterparts from Australia, the United States, the United Kingdom, Canada, Ireland, Austria and East Africa, our challenges and constraints in projects are not markedly different.

Are conference attendances useful in delivering better projects

As I was attending various presentations during the week, it was quite a pattern. Most presentations covered what the project did, followed by a demonstration and discussion on technology used to deliver those feature functions. This is in keeping with other similar conferences I have attended over the years. What we most often do not share in these industry forums is what outcomes the customers were looking for, challenges the delivery team faced, tradeoffs the customer had to make because of this, which resulted in the final shape of the project as it was delivered. I found it far more useful to talk to some of the presenters after their talks. I found they were much more relaxed and readily forthcoming with the kind of information I was looking for.

Delivering IT projects are interesting exercises even at the best of times. On my flight I was talking to a company director who was quizzing me on why IT projects fail so often. From his point of view such projects are usually one of the top CAPEX projects in companies that he and fellow directors worry about. He had a valid point. If I had a ready made answer for this, I would be a millionaire. My main goal attending these conferences it to ensure I can minimise having to learn lessons first hand that my peers have learned from making mistakes.

It is a delicate balance however. Having spoken to my peers around the world, it seems that same approaches have worked in some parts of the world and failed miserably in others. Some approaches that we had discounted seems to have flourished elsewhere. It is key therefore just to not look at results on the surface, but also understand the cause of such success or failure. Conference settings are notoriously difficult to delve to that level of detail. I have also found that we are much better at scrutinising things that have not gone well and less aware of what made our projects successful. It seems success makes us complacent.

You have to always remember to not take away half baked ideas as learning. This is where the connections you make in such conferences are gold. If you stay in touch with like minded peers and exchange ideas, this can form a huge source of information and a place to test your ideas before you jump in at the deep end.

How good are we at lessons learned?

We as human beings have the incomprehensible ability to make the same mistakes over and again. You have to take a glance at history to see the same pattern repeat itself – a nation is enlightened, makes rapid progress, gets intolerant and starts to impose itself, loses its hold and goes back to the pack. Chinese, Persians, Romans, Greeks, Ottomans and Arabs – all had a go. In recent times Great Britain and the United States. It is therefore not surprising that we do the same with projects.

Lessons Learned

One of the PRINCE2 principles is to learn from previous lessons. Good in theory. How well is it done? Not very well in my view. Lessons learned is something that is left to the end of the project in my experience. On any sizeable project, the project team should be implementing lessons learned as they go. Lessons learned is not only for not repeating the mistakes of one project in another, it is also to ensure mistakes of one task in the project is not repeated in another.

The difficulty of recording lessons learned is very similar to that of benefits realisation in a project. By the time people have some ability to look into that, the project is completed, and attention has shifted to the next project, or towards embedding the products of the project into the organisation. Keeping focus to ensure this is captured takes a lot of discipline. Standard practices are also required for capturing lessons and reviewing those at the initiation stage of any projects. Otherwise, the lessons are not worth the paper (or disk space) they are captured on!

What things should you capture as part of lessons learned? The first and foremost thing you must capture is your estimated effort versus actual time spent. Estimation is an inexact science. Projects by nature are risky and whatever methodology you use to estimate, it is a matter of continually refining those. The bare numbers are not sufficient. You must analyse what led to those numbers. You may have estimated high, but because of scope creep you may have come on budget. Was that success or failure?

A second thing I recommend is the identification or risks. Were there issues which were not identified as risks at the outset? If not, what led to those issues? How could they be identified better in future? Where issues were identified as risks at the outset, review the risk responses. Were they appropriate? Were the likelihood, impact and proximity identified correctly? If not, try and analyse how it could be done better.

I would also look to see if the project methodology was tailored to suit the project and the organisation. Many organisations think using a methodology like PRINCE2 will ensure success. Without the appropriate tailoring, methodologies are doomed to failure. It is not the methodology that brings success, it is the people that understand the principles and ask the right questions that make the difference.

These are by no means an exclusive list. In many ways you should look to evaluate each of the six tolerances that the organisation affords a project manager – time, cost, scope, risk, quality and benefits. The three above are the most common causes of repeat mistakes from my experience.

Image Credit: Ryan Renfrew

The peril of quality lapses

Having a week off between jobs has given me the chance to spend a bit more time looking at the world in general. One news that particularly came to my attention is the case of a simple spelling mistake that has caused plenty of red faces for the Republican US Presidential hopeful Mitt Romney.

This story shows all the hallmarks of leaving a developer to produce an application while little or no effort was given to ensuring the output was of a quality that would achieve the desired outcomes – rallying supporters. This is not something that will necessarily define Romney’s campaign to become the President. Neither did Romney make the mistake personally. His mistake was to hire staffers that were sloppy. In the days of spell checkers it is not a mistake that should get this far. Mistakes do happen, some more visible and embarrassing than others. On a week he has sealed the Republican nomination, he would have been looking to go after Barack Obama’s record as president. Instead, his staffers are left cleaning up after this gaffe.

The result of missing or ignoring some basic quality assurance measures can have significant adverse outcome. While this one was limited to some red faces, other instances can have severe consequences. Never assume quality is under control or someone else will ensure it. As project management professionals, it is our role to define acceptable quality criteria for the project outputs and set out processes that will achieve those.

Then again there are the likes of Kim Kardashians of this world who revel in adverse publicity … for her the quality criteria may be to ensure a big talking point!

Image Credit: CNN

How do I manage a distributed team?

As the world becomes smaller due to more efficient communication, distributed teams are becoming quite common. If you ring a customer service line in any country, the odds are you will end up being serviced by someone in Manila. Your latest Microsoft software was most likely developed in Bangalore. I have been managing projects with teams and clients  scattered in different parts of the country, and in some cases spanning multiple continents. I have been thinking about some of the challenges I face and how best to overcome them.

The biggest and most obvious challenge faced in managing distributed teams is the fact that you are not where they are. Even with all the new technologies, talking face to face remains the best form f communication. There are many forms of communications in projects – the truths, the half truths and the outright guesses. When you are managing the deliverables, you need to be on top of what is what. While this is not an insurmountable obstacle, it is a rather expensive one to mitigate. People work best with people they have known personally. They are more likely to be upfront with realities, than someone they find hard to relate with.

Working in different time zones also amplifies the problem. As an example, I work out of New Zealand and work with people in the west coast of the United States. During the southern hemisphere summer, it is reasonably workable, with abou 5 hours overlap. However, we lose a day. So we get about 20 hours during the week. In winter, during the Pacific Daylight Time, the overlap is as little as 12 hours. Our other base is in India, which starts work as we are leaving for the day.

Work cultures vary in different parts of the world. That plays a significant part in bringing a team together. New Zealand has a very relaxed working environment and an excellent work life balance. This is not to say, Kiwis are lazy by any nature. A lot of our innovation comes from this part of the world. I find Americans are much more intense with their work and put in significantly longer hours. Consequently there is always possibility of conflict if the teams perceive each other to be too pushy or too relaxed. Work cultures also vary in how people communicate bad news (or how they do not). While you do not want bad news in projects, if it does  pay to get it early.

If you are indeed managing people from all the different locations, the likelihood is you are not their direct line manager. They are each likely to have their own line managers to keep happy. This in itself is not uncommon in a project scenario. Temporary assignments from operational teams is a routine occurrence. It is quite different when you are not there to ensure the story you get is the reality, rather than the party line.

You can alter your usual working hours to accommodate additional collaboration between the teams. You can utilize advanced telecommunications to give a feeling of co-location and one team culture. These are all good measures, but intermediate ones. The more the teams are isolated, your picture will be less realistic and you will struggle to enforce uniform processes across the teams. The only way to bridge that gap is to ensure regular face time.

If it s important enough to have distributed teams, it is important enough to ensure effective management.

%d bloggers like this: