Why Projects Suceed - Articulating the Value of Project Management

Balancing Strategy and Tactics

By connecting the dots between tactics and strategy and creating a balance between the two, the successful Project Manager provides true leadership to team members, stakeholders and the executive sponsors. That balance is required for any project or campaign, as illustrated by one of my favorite quotations:

“Strategy without tactics is the longest road to victory. Tactics without strategy is the noise before defeat.” - Sun Tzu

Or as I like to paraphrase…

“Tactics without Strategy: a lot of running around. Strategy without Tactics: a lot of sitting around.”

OK, I’m not as poetic, poignant, or published as Sun Tzu, but you get my point. The successful Project Manager provides this balance for their teams and projects and ultimately ensures effective commitment management and value generation.

Summary

Driving “value” is only part of the battle for Project Management. Being able to articulate that value is crucial for successful Project Managers. Whether it’s motivating team members to participate in project activities, or getting stakeholders to pay attention to your project requests, describing the value of project management so that it is understood by stakeholders is a key to project success.

Get full article by Roger Kastner at:
http://www.pmhut.com/why-projects-succeed-articulating-the-value-of-project-management

More about the Author:
Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.

Is Project Management the New Quality?

In the 1980’s and 1990’s quality management seemed to be taking over the world’s organizations and businesses. It seemed quality improvement, kaizen, value added management, LEAN, six sigma and so on were all seen as the tools for helping organizations improve performance every year. A large number of the world’s best practice organizations led the way with massive investments in training, systems, equipment and culture change programs. It now appears that most of these organizations that were leading the charge to quality have largely led the retreat as well. Few organizations now seem to have highly paid Quality Managers, Quality Departments or Quality Systems as such.

In the 1980’s and 1990’s it was often said that organizations had to improve somewhere around 10% year on year just to stay relevant compared to competitors and constant changes in technology.
Constant improvement and prevention of errors, waste and mistakes, I believe, is built into most of us.

If that is correct then my question now is: If quality improvement was so vital to every organization’s success then, how is it happening now?

My answer is project management.

Organizations, both public and private sector have embarked on a huge project management kick and most don’t seem to realise it. A cursory review of job titles in the public sector has thousands of staff with project in their title. They could be project managers, project team members or project officers but most are not formally trained project professionals and don’t really do formal projects that would meet today’s definition of a project.

How did this happen and what does it mean for organizations?

I believe it happened because quality became too expensive, too difficult, time consuming and too risky to stick with and far too hard to obtain tangible results that could be directly attributed to the quality effort. You can have the greatest product in the world but people have to see the need to buy it and reasonably believe that it will produce the desired results. In the end after such a huge investment there had to be significant results and in a lot of cases these results couldn’t be put forward for all to see. The belief was no longer there.

In today’s climate it is much easier to sell executives and decision makers the concept of project management as a “go forward” type vehicle for most organizations. This has, just like quality management did before it, generated a support industry made up partly of zealots and believers established to support organizations through their project management transition. This means training, accreditation, materials and record keeping systems to accommodate them all. One of the other negatives is the amount of energy some industry insiders are happy to spend arguing/discussing the merits or otherwise of the various project management methodologies available and which one is “best”.

Amazing how wedded some people get to methodologies instead of being more interested in getting the best results. Reminded me of the old quality management days.
Progress down the project management road so far is pretty mixed to say the least. Catastrophe databases have appeared on the internet documenting some of the more spectacular project failures around the world.

This makes depressing reading.

The private sector and the public sector seem to be both struggling to successfully deliver major projects, especially IT projects. It almost seems at times that the projects are managing the people and not the other way around.

In this country, we have a public transport ticketing system that cost taxpayers more than the last Mars landing. We have a payroll database brought in at a budget of $40M that still doesn’t pay staff the correct salaries and has blown out to $400M so far and still going. There was a federal government initiative to encourage home-owners to get roof insulation installed in their houses to save energy. Included in the unintended consequences of this project were four fatalities including a number of young and inexperienced installers who tragically and unknowingly ended up in harm’s way just trying to earn a living. This project was obviously a rank failure as soon as the first person lost their life but it should be noted that professional inspections were then required for 50,000 dwellings and a further hundred or so houses burnt down as a direct result of the project.

It is the same overseas as well. There is a litany of spectacular project failures in driver’s license databases, stock market programs, travel systems, baggage handling systems, construction projects, disaster management restoration programs and now, more recently stimulus spending programs.
There is research that suggests that around 1/3rd of all projects fail in progress and are abandoned before they are finished. It also seems that roughly half of all projects come in close to double their original budget.

The research also suggests that around 1/6th of all projects come in on time and on budget.

Is this good enough? I think not.

What can be done about it?

Will project management eventually join quality management and the dinosaurs and be consigned to the history books?

Article by Stewart A Brown for PM Hut.

More bout the author:
Stewart A Brown is the Managing Director and owner of Blueprint Planning Solutions Pty Ltd.
Stewart holds a number of qualifications including Mechanical Engineering and Development, Quality Technology and Quality Improvement. Stewart earned a Graduate Diploma in Quality and a Masters in Business from Queensland University of Technology. In addition, Stewart has been trained by Nippon Light Metals in process improvement and has accreditation to deliver KAIZEN projects. Stewart has also delivered many training sessions using Value Added Management, Project Management, Decision Making and Process Improvement Tools and Techniques. Stewart was an accredited Team Leader for the Australian Business Excellence Awards and has also served as a team member for the Australian Mining Industry Safety and Health Awards.

Reacting to a Problem

Things go wrong in projects, that’s fair enough. Lets take it as read that your trying your best to identify, remove or mitigate risks (if not stay tuned for more articles on the ins and outs of risks soon). But what do you do when something goes wrong, something that you under estimated or just plain missed (and this happens to all of us.)

First things first you need to understand what the impact of the problem is. Not the running around waving your hands screaming everyone’s going to die sort of impact, but the sober, sitting back, emotionally removing yourself for a moment and analysing from different perspectives sort of impact.

To get started consider who is actually involved and try and put some numbers on them (it’s usually less then you expect), next figure out the ways in which people have been impacted and split people above out into these groups. Write all this out and you’ll soon have a pretty good idea of what the actual impact is and you’ll have calmed down and feel a new mastery over the situation! By completing this little exercise you’ll now have a well defined tangible problem against which you can plan out your actions.

Article by Pete Winn(http://www.petewinn.co.uk) for PM Coup

Project Management Knowledge Versus Technical Knowledge

As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge.

There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat."

Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture.

When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience.

Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team.

Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources.

Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise.

Article by Dmitri Ivanenko for Voices on Project Management
http://blogs.pmi.org/blog/voices_on_project_management/2012

Change happens...so embrace it!

Change is nothing to be afraid of; in fact if it wasn’t for change, there wouldn’t be a need for project management.  Isn’t that what we do as project managers; manage change?  Yet often I have noticed that some don’t understand what they should do when change occurs in their project.  I believe the reason for this fear of change is because they react to change rather than plan for change.

The Doberman

A few years ago I was helping my son with his paper route.  I was driving him around the route because this one Sunday’s edition happened to be quite large due to the number of advertisements.  I remember watching him approach one particular door, but before delivering the paper, he made an abrupt turn and raced back to the car.  I saw fear in his face as he approached me and I asked him why he didn’t deliver the paper.  He informed me that there was a ferocious Doberman at the house and he was not going to deliver the paper.  Before I knew it, Dad was volunteered to deliver the paper.  As I approached the door, I discovered that the ferocious canine was indeed just a little Dachshund, a Weiner dog.

Four Keys to Managing Change

Just as my son was afraid of something he wasn’t expecting, we can be afraid of change if we are not prepared to manage that change.  Here are four key things to remember, which if followed will help us be prepared when change happens.

1.  Make sure there is a change management process in place.

Either the organization or the project should have a well defined change management process implemented so you will know what to do when change occurs.  The project manager needs to be able to understand, who approves changes, what steps must be followed to get that approval, and what mechanisms are required.

2.  Have a solid scope, budget and schedule defined.

This is critical because change can occur to any three of these constraints.  A shareholder can request additional scope be added to the project.  Management might decide to decrease the budget due to funding constraints.  The market might dictate the project needs to be delivered earlier than planned.  When these three constraints are well defined, you will have a baseline in which to measure the change.

3.  Analyze the impact to the project.

The project team, lead by the project manager, should analyze the impact of the change to the defined scope, budget and/or schedule.  This impact will be documented and presented to the decision makers of the project.

4.  Insist on a decision prior to acting on the change request.

Based on the documented impact and following the change management process, get a decision for approval or rejection of the change request.  Don’t make the mistake of acting on a change request prior to obtaining an approval from the decision makers.

As you follow these key recommendations, you will be prepared when change requests hit your project…and you won’t be afraid.

Article by Mark Phillipy (http://www.sensiblepm.com/change-happens/)

About the author:

Mark Phillipy is the Sensible PM. I have over 15 years of project management experience in the IT industry. I have been involved in all aspects of software development and implementation using both traditional Project Management methodologies as well as Agile methodologies.

Nontraditional Ways to Get Feedback for Lessons Learned

When capturing lessons learned, feedback can come from anywhere. Don't dismiss comments because of how you receive them.

Consider that you may want to receive feedback from the quality assurance manager who's always on the run. Talking on a mobile phone while he or she is driving from site to site may be illegal, though.

Or consider the database administrator who transitioned off your project in phase one, who no longer has security access to the project, and is now busy on her next project.

So how do you get their feedback?

It isn't easy to reach out and receive the lessons your stakeholders may want or need to share toward improving the next project.

These two unconventional communication methods can be used to help in lessons learned:

• Try a text or Twitter message. Texts and social media aren't only for the younger generation. But to use them, you must to be concise. You may ask your stakeholders to drop a quick message and provide more detail later when they may have more time. 

• Host a blog site. Start by setting up categories to receive feedback on particular areas of the project, for instance. Using the categories will allow a better way to coordinate the comments, and give the stakeholders a fast way to respond.

In lieu of attending an in-person project review, receiving lessons learned material by other traditional methods could work as well. Contact a stakeholder by e-mail. Dial the person on the telephone. No matter what, reach out for feedback.

Article by Bernadine Douglas for Voices on Project Management.

A Project With No Project Charter?

Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project.

Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.

However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.

Why?

Here are some reasons a charter is left out, based on my experience:

1. Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
2. At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
3. The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
4. Requirements and other changes to the project deemed the existing project charter obsolete.
5. The project has been initiated or is continuing without real executive commitment. 
6. The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.' 
7. A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
8. Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.

However, without a charter, a project is headed for problems including:

Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.

Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.

Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.

Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.

Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.

Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.

Article by Saira Karim for Voices on Project Management