Project Planning – One of the Most Essential Steps to Take in the Management of Your Project

Project Planning is one of the most essential steps to take in the management of your project. Produce a good Plan and go for it!

However, before I get into the specific ideas concerning planning and how I recommend that you do it, there are a number of things that I would like to say about the subject at an overall level.

First of all, when I talk about a plan, I define it as a scheduled list of interrelated Stages, Products, Activities, Milestones, Tasks, etc. along with assigned resources, estimated effort and planned elapsed time.

I believe that having a proper Project Plan is probably the second most important thing that the Project Manager must have in place. I say the second most important thing but I know  you can’t have two most important things. But if you could it would be the Requirements Specification and the Project Plan. I worked as Program Director for the CEO of a bank in London once who told me that the most important thing was the successful completion of a program I was managing while at the same time telling me that the other most important thing was a second program I was leading. There you go – two most important things.

In terms of Project Planning, I’m a firm believer in what Zig Ziglar says and he was probably not the first one to say it. “Failing to plan is planning to fail”.

Without an agreed, integrated Project Plan in place how does anyone on the project have any idea what they are supposed to be doing, when they are supposed to be doing it, who is depending on them doing it, when the various Milestones are going to be met, when the project will be delivered, and I’m sure I could think of loads of other reasons for the plan if I took the time. But, I think you get the picture.

If you want to ensure project failure, discontent on the project and chaos, just refuse to put a good Project Plan in place. By the way, in my experience, the lack of a detailed, well-structured Project Plan on a project is the second of the top 10 reasons that projects fail. The first reason is the lack of a detailed, agreed Requirements Specification.

And lastly, I’ve found that for a plan to be accepted and agreed to by the Project Team, the customers and all other stakeholders on the project, they must be part of the production of the Plan itself.  One of the worse things that a Project Manager can do is create the Project Plan without the assistance of those involved or affected by the plan and then expect them to be committed to it. It just won’t work.  You must have their involvement to get their commitment..

So join me on my next few articles when we’ll talk about the structure of the Project Plan and the steps you need to go through to prepare it.

Richard Morreale is a professional speaker, author, trainer, and c-suite consultant specializing in Program and Project Management, Change Management and Success Strategies. For more information or to book Richard as a speaker email him at richard@richardmorreale.com or ring him at 336 598 2793.

One of the Major Reasons Projects Fail – No Agreed and Controlled Requirement

Let me first of all define what criteria I use to determine if a project is a failure or not. The criteria I use is cost, schedule and expectations. I believe that a project is a failure if it costs more than what was approved, if it was delivered later than the approved schedule, if it did not meet customer expectations.

In all of my audits and reviews of Information Technology (IT) project failures – large and small, I’ve found that the top reason for failure is the lack of agreed and controlled requirements. In other words, the project team did not have a clear picture of what the customer wanted the team to build and deliver. And, in cases where there had been a clear picture of the requirements, changes to that clear picture were made but were not controlled properly.

I’ve always tried to work out why a Team of people would start building something before they knew what it was they were supposed to build or before they had a clear picture of what it is they were supposed to deliver. It’s just plain foolish, isn’t it? It’s easy to see how foolish it is if you were dealing with a builder that you hired to build your house. Before he started, you would definitely have blueprints, specs, etc. for the builder to follow. In addition, you would have agreed the cost and the delivery date. I know you wouldn’t just tell the builder to start without both of you understanding and agreeing the plans, specifications, costs and schedule.

So why do IT people do it? Why do IT Teams start building before they have it locked down as to what it is they must build? Well, let’s take a look at a number of reasons why I think they do.

One reason is that Senior Management, in most cases, are pushing for a delivery date that is usually very tight and usually not particularly feasible. So Project Managers feel like they need to take some short cuts to deliver on time. And one of the short cuts is to start working on what they believe they have to deliver before what they are supposed to deliver is documented and agreed. Or they say things like, “Let’s get the work started, we’ll do the documentation later”. And, of course, the documentation never gets done.

Another reason is that the development team members think they know what the customer wants and, therefore, they think they can get a head start and begin working on it before they finish discussing and documenting what the customer really wants.

An additional reason is that there is no process in place that defines how to go about delivering a project and, therefore, the Project Manager makes it up as he or she goes along and decides that a Requirements Document is not needed.

Starting work on a project before you know what it is that you are supposed to deliver at the end is always a mistake – A big mistake.

So, take the time to get a Requirements Document prepared, agreed and signed by at least the developers and the customer. File it in the project library and put it under strict Change Control.

Some of the benefits of doing this are:

• You and the team start off the project knowing what it is that needs to be delivered,
• It provides you with a firm baseline on which to develop your cost and schedule estimates,
• It provides you with an approved basis for evaluating proposed changes,
• It provides you with the basis for the preparation of System Test Specifications, and
• It helps in the communication between you, the development team, and the client.

So, make sure that you and the team know what is supposed to be delivered before you start working on delivering it.

Enjoy the Journey,

Richard

Richard Morreale is a professional speaker, author, trainer, and c-suite consultant specializing in Program and Project Management, Change Management and Success Strategies. For more information or to book Richard as a speaker email him at richard@richardmorreale.com or ring him at 336 598 2793.

What it Takes to Be a Great Project Manager (Part 3)

For the last 2 weeks, I have been Blogging about what it takes to be a great project manager. And if you are a project manager why not be the best you can be. What fun is there in just being average? The better you are the more opportunities you will have. After all, for those of you who can remember Tina Turner, how many singles do you think she would have sold if her hit song was  titled  ‘Simply the Average’? My guess is not many. That’s why the song was named ‘Simply the Best’. So let’s do whatever it takes to be ‘Simply the Best’ at what we do. There I go, preaching again. Sometimes I just can’t help myself.

At any rate, two weeks ago I wrote about the Hard Skills that make up part of the Project Management Greatness Equation. Last week I covered the Soft Skills that make up another portion of that Equation. And today I am writing about the Project Manager being a Master of Paradox. Let me explain what I mean.

I believe that a project manager must have a big ego. That is they must have the confidence that they can deliver almost anything. I mean, I’ve never built a bridge but I do know, without a doubt,  that I could manage the building of a bridge. Basically, I would use the same Project Management Hard and Soft Skills that I’ve used in every other type of Project. While I have the confidence that I could do it, I also need to have a small ego. An ego that would permit me to give most of the credit for the successful delivery of the bridge to the team because without them nothing would have been done. Big Ego – Small Ego.

The Project Manager must be not only a manager but must also exhibit the skills of a leader. The leader establishes the direction in which the project should go while at the same time motivating the team to go in that direction. The leader establishes the vision. The leader helps to ensure that the team understands the vision. The manager works with the team to identify the steps that must be taken to go in that direction. The manager, with the help of the team, plans, organises, monitors and controls the project. Leader – Manager

The Project Manager must be able to handle the ambiguity that sometimes is inherent in a Project. Not everything is known when the project manager would like for it to be known. Other projects interface with the project and have their requirements that could make the actions to be taken on a project ambiguous. At the same time the project manager needs to continue to search for  perfection surrounding his or her project.  The project managers must be able to live with the ambiguity and at the same time help his team live with it. Ambiguity – Perfection

The Project Manager must be able to handle the complexity of the project while at the same time be always searching for simplicity. Some projects are very complex and, in fact, they seem to be getting more and more complex as we go along. Complexity is sometimes very hard for people to deal with. It is the project managers responsibility to help his or her team deal with it while at the same time be always searching for simplicity. We need to remember that sometimes people make tings a whole lot more complicated than they have to be. Search for the simplicity and make it clear. Complexity – Simplicity

The Project Manager must be able to have the helicopter view  of the project and understand the big picture. How the project fits into the grand scheme of things – how the project interfaces with other projects – how the project affects other projects from, say, a resource standpoint. In addition, the project manager must be able to, at times, get into the details – see the small picture. Sometimes that is the only way he or she can get the information required to make big picture decisions. So the project manager needs to see the small picture when required and then be able to step back to the big picture view. Big Picture – Small Picture

The Project Manager must be impatient and expect things to be done with a sense of urgency. He or she must have the skills necessary to establish this sense of urgency on the project without causing harmful stress. However, the project manager must, at the same time understand that in some cases patience must be the watchword because patience is sometimes required to establish the  relationships required to run a successful Project. Impatience – Patience

So there you have it – what I mean by being a Master of Paradox. Whether you agree or not, I would be happy to have comments from you about this Blog or any of my Blogs, for that manner

Enjoy the journey,

Richard.

Richard Morreale is a professional speaker, author, trainer, and c-suite consultant specializing in Program and Project Management, Change Management and Success Strategies. For more information or to book Richard as a speaker email him at richard@richardmorreale.com or ring him at 336 598 2793.