Duncan Haughey

Successful Projects: It’s Not Rocket Science

by Duncan Haughey

Project Management is not rocket science

Project Management is not rocket science

There is no worse person to be than the project manager at the end of a failed project. As an IT project manager, I have experienced that feeling and I can tell you it’s not nice. IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them.

The trouble with these projects is that often you are doing something that hasn’t been done before, is unproven or cutting edge. Customers expect a good result not excuses, even though these projects are frequently a journey into the unknown. If we take the construction industry, building a new bridge for instance, we have been building bridges for hundreds of years and know how to do it. We understand how things are going to happen, in what order and the expected result. This is rarely the case with IT projects.

Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. Identified here are five killer mistakes of project management:

Who Owns the Project?

The Mistake:

The nature of projects is change and change often encounters resistance. People don’t like change so they need to know it is necessary and what benefits it will bring. In order for a project to deliver change it needs the backing of senior management. Without it the project will proceed very slowly. The sponsor (senior management) is the person that drives the change forward and the project is the mechanism for change. A project without support from senior management will struggle.

The Solution:

Make sure you have the top down backing from senior management. There must be direct communication from the sponsor to the stakeholders. The message must be, “we are serious, this thing is going to happen so you are either with us or you are not” and beware those that are not.

Be careful as project manager to make sure the sponsor does not take the project over and become the de-facto project manager.

Getting Users Involved

The Mistake:

Lack of user input and involvement is the recipe for a bad project. This can either be because of the “we know what you want” mentality from the IT department or lack of interest from the customer. Either way it must be avoided.

The Solution:

The IT department must take time to understand the customers requirements before proposing any technical solution. Often IT is blinded by the latest, newest thing available and try to shoehorn the requirements into it. On the other hand, customers must devote the time and effort necessary to ensure a successful project by interacting with the IT department and making sure all requirements have been fully defined. Ensure you have spoken to all stakeholders to gathered their requirements and that they continue to work with you for the duration of the project.

Stopping Scope Creep

The Mistake:

Scope creep is the cause of more project failures than anything else. Not knowing exactly what a project is aiming to deliver or setting off in a fit of enthusiasm but little else, is a recipe for failure.

The Solution:

Ensure that the business case, requirements and scope are clearly defined and documented. Make sure the stakeholders understand them and sign them off. Stick rigidly to the scope and if changes are required then put them through a change management process where they are documented, justified and then agreed.

Managing Expectations

The Mistake:

Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a technology project expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.

The Solution:

One way to avoid this is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with IT projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to demonstrate what the technology can really deliver. This approach ensures the project delivers to the customers expectations by giving them early visibility of what you are building.

Understanding the Lingo

The Mistake:

Have you ever stood next to a group of IT professionals and wondered what on earth they were talking about. It is like a whole new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.

The Solution:

Communication problems are the hardest to resolve as often it is only looking back that the problem is identified. Regular communication and a close working relationship with the customer will help. What you really need is a person with a foot in both camps. Someone who understands the business and the IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next best option is to have two people, one from the business and one from IT. By working closely together and sharing information they can minimise any communication problems.

Finally

In 1995 The Standish Group surveyed IT executive managers for their opinions about why projects succeed. The three major reasons given that a project will succeed are user involvement, executive management support, and a clear statement of requirements. Concentrating on these three aspects alone will give your project a good chance of success.

Don’t become the victim of a failed project, put measures in place that will ensure your success. After all it’s not rocket science!

Read more about IT Project Management

{ 6 comments }

Avoid the Same Old Mistakes by Focusing on Lessons Learned

by Duncan Haughey

Lessons Learned

Lessons Learned

It’s said there are no new project management sins, just old ones repeated. It’s also said that we don’t learn the lessons from past projects and this must be true, otherwise why would we keep making the same old mistakes.

In his article, “Lessons Learned: Why Don’t we Learn From Them?” Derry Simmel, board member of PMI’s PMO SIG, identifies two common problems preventing us learning valuable lessons from past projects:

  1. We think the lessons don’t apply to us.
  2. We want to get things done

“The sad truth is that these lessons learned are useful. That time spent in doing the work better is time well spent. That getting it right the first time is cheaper and easier than doing it now and fixing it later,” Derry says.

So if we accept that lessons from past projects are indeed useful and can prevent problems later down the line; how can organisations create a lessons learned culture where people not only take the trouble to learn from past projects, but actually want to learn. A culture where we apply best practices and discard bad ones.

Leadership

For new initiatives to succeed it’s usually best to take a top down approach. The organisation’s senior leadership need to foster and support a lessons learned culture. This is likely to be more successful and long lasting than a bottom up approach, although this could have limited success if project managers promote it strongly themselves.

Given top level support, enough time and buy-in from project managers, lessons learned will become part of the organisation’s culture and part of its continuous improvement process.

Process for Capturing Lessons Learned

If project managers are going to actively contribute to the project management knowledge within an organisation and make use of it, then we have to make it easy for them. Nobody is going to go out of their way to do it. So it’s important to have a well defined and simple process for collecting, collating, analysing and disseminating lessons learned. It could be along the lines of discover – recommend – document – share – review – store – retrieve.

Discover

Project teams should learn to identify lessons during projects and record them for inclusion in a lessons learned report at the end of the project. This might be done as part of their regular team meetings.

A sign that a project may be having a “lessons learned moment,” is when the resources or customers are unhappy and discussing problems between themselves outside team and other project meetings. Lessons may also crop up during a project when team members identify areas for improvement.

Arrange regular brainstorming sessions with the project team, with an independent facilitator, to unearth valuable lessons. Don’t leave it until the end of the project when memories have faded.

Lessons can be discovered by asking these three questions:

  1. What went right?
  2. What went wrong?
  3. What could have been better?

Use the facilitator to document the lessons, keep the meeting focussed on key issues, and steer the discussion in the right direction.

Recommend

Project managers and their teams should make recommendations. What would they do differently if they could go back and start over again?

This needs a degree of honesty that some team members may find uncomfortable. The feedback needs to be constructive and avoid getting personal. We are not looking to play the blame game here; we need to understand how things could be done better in the future.

For this to work effectively the organisation’s leadership needs to reward this honesty, and demonstrate it will not have a negative impact on individual careers.

Document and Share

It is important to document and share findings. The best way to do this is by creating a standard lessons learned report and a repository with good meta-data to help with identification. This should be kept updated with lessons from the most recent projects in order to take account of the current working environment, structures and constraints.

Standard format reports and meta-data will make it easier when reviewing multiple documents and searching the repository using keywords and phrases.

Review

It is the job of the Project Management Office (PMO) to review lessons learned reports and pull out issues that arise multiple times. Recurring issues can be surfaced and presented in a general “read this first” list of lessons.

The PMO must look at what makes projects succeed and what makes them fail, and give recommendations that sit along side those of the project teams.

Store

Lessons learned must be stored in a central repository with general access. Create a system for storage and retrieval of lessons. Online systems are ideal for this, giving easy access to the lessons. Most organisations have portals and Intranets that can be used for this purpose.

Retrieve

Retrieving lessons learned on a regular basis must be part of the organisation’s culture. Project managers should be expected to retrieve and review lessons prior to commencing a project. They should have this as part of their annual performance objectives and be able to demonstrate they have retrieved, reviewed and applied lessons wherever applicable.

Summary

Creation of a successful lessons learned culture needs leadership support as well as time and buy-in from project managers. Implementation of a simple process for collecting, collating, analysing and disseminating lessons learned is essential if it’s to be adopted.

Once lessons have been captured, they need to be made available to all project teams to help them avoid repeating problems of the past. It is important that these teams understand what past projects have to tell them and act upon that information.

History has a strange way of repeating itself. If we don’t take time to learn the lessons of the past, and moreover act upon them, we will continue to commit the same project management sins again and again. And don’t think it won’t happen to you, it will.

Remember, in the words of Derry Simmel, “…time spent in doing the work better is time well spent.”

Read more about Lessons Learned

{ 5 comments }