Wednesday, September 14, 2011

The Secret Of Successful Project Management

By Jessica Paul

Speak to an experienced project manager, and they can give you a wealth of good advice on the do's and don'ts to successfully manage any project. All this advice, in a nutshell, would be about how to manage the people doing the work (that includes you too), to deliver their results on time and to a budget, while keeping the risk of failure to a minimum.

It really doesn't sound that difficult to do, but for some reason, many people think that project management is a massive overhead to any project. I often hear phrases like "oh, don't waste your time planning the work, just do it!" or "why are you wasting your time writing the objectives, we all know what needs to be done!".

So the number one secret to successfully manage any project is:

"Understand the few essential brief documents you need to create and regularly review during the life of your project."


For example, at the beginning of your project, you need to create a one-page document called the Project Charter. This document will make sure that you and your customer understand the general goals of the project. After all, if you don't know where you are going, how are you going to get there? Remember, you could also be your own customer!

To get this information, have a meeting with your customer and ask the following 3 essential questions:

1. What are the objectives of your project?
2. What do you want to produce or deliver?
3. What is the business reason for doing this project?

After the meeting write the answers to these questions in your Project Charter and email this back to your customer and ask them for their approval.

You have now successfully completed the most important aspect of any project, and that is to understand and agree with your customer where you are going with this project.

If you look at the time spent to achieve this important step in a project, you are looking at one or two meetings and about 30 minutes to write up the information, say 2 hours in total for a small project. Not a big overhead at all.


You can now get on and create the second document call the plan. This will include a list of the work that needs to be done (also referred to as the scope of work), who will do it, the cost and time to do this work, and finally a simple review of what will go wrong (known as a risk assessment).


On a regular basis, anything from weekly to monthly, you need to create a progress report and deliver this to your customer. They want to know what work was done, when, and how much was spent. They also want to know if you need their help to solve any problems. Your major challenge is just collecting this information so that you can create your regular progress report.


I have described the absolute minimum information you need to manage any project, and the secret to success is understanding the few essential brief documents you need to create with this information - the Project Charter, the Plan and the Progress Report. I hope it leads you to success in your projects.

Problems Not Solved by CMMI nor Agile

This article is extension of ours previous articles for CMMI and Aglie methodologies. You can check them by choosing CMMI and Agile from Categories/Menu.

Part One of each CMMI model describes three aspects of development projects as (1) processes, (2) technology, and (3) people. CMMI makes no secret that it focuses on processes.

Meanwhile, Agile methods clearly focus on people and allow people to determine technology and processes. Regardless of the focus of CMMI or Agile, neither can entirely prevent simple human error, departure of key personnel, impact of incompetent personnel, active or passive insubordination, or deliberate sabotage. Neither can prevent the effect of an employee’s personal life on his or her job performance. Each body of knowledge can have mechanisms to catch and manage such matters, but neither can prevent them any more than either can prevent the local economy from creating a scarcity of qualified employees.

Most organizations have experienced ill-fitting employees and the corresponding challenges in placing them or keeping them employed or happy. Most organizations have had to deal with employee losses, loss of project funding, evaporation of technology resources or suppliers, supply and demand in the marketplace, premature obsolescence of core architectural components, and other issues beyond their immediate control.

While derived and adapted abilities can positively influence the non-development aspects of product and service development, there are many aspects to development that neither CMMI nor Agile, as a first tier implementation, are meant to affect. The conclusion here is that neither CMMI nor Agile are panaceas to all that may hinder development.

Perhaps simply a special guidebook for appraising Agile organizational units or projects or a set of Agile alternative practices associated with CMMI goals accompanied by an overview of Agile values and practices would prove useful.

Fundamentally, misuse is a problem for both CMMI and Agile. One of the original signatories of the Agile Manifesto recently wrote that he was hired to perform due diligence by a venture capital firm that had decided to invest only in companies practicing Agile methods. He found that of the companies he visited and examined, only three percent of those claiming to use Agile methods were actually doing so. (Whether another signatory would judge a similar percent is of course a different, though related issue.)

One of many forms of misuse includes aspects of practice introduction entirely unrelated to either Agile or CMMI. Introducing new practices poorly will likely result in failed implementations regardless of what is being introduced. During a panel session on Agile at SEPG 2006, an audience member asked the panel about an Agile implementation failure at his company. The context of the question was that the adoption of Agile was an executive edict with unrealistic expectations of return on investment, disconnected goals, absent the Agile principles, and devoid of the cultural necessities of long-term change success.. This situation was an organizational behavior matter that neither CMMI nor Agile could immediately resolve.