Quality Projects Take Time and Money

By Joseph Phillips

Have you had any great customer service lately? No? Me either.

Customer service, or the lack thereof, is unbelievable - especially in restaurants. My favorite watering hole, well it's hardly a favorite, but it's a safe distance from home, has some horrible service. It seems that the waiters, waitresses, bartenders, are more interested in their pub drama than in getting me my reuben sandwich and frosty brew.

So why do I go? Other than it being close to home, their food is tasty, the beer is always cold, and it's priced right. I know what to expect and they usually deliver. When I visit, I can expect to be ignored, overlooked, looked over, and then eventually served. I can expect a fair price for a decent meal. I can expect the same end result every time. All in all, they meet my expectations.

I'm sure you have similar restaurants, stores, and services where you live: you aren't overly impressed, but they deliver to your level of expectation. So what would you do if you went to a four-star, high-dollar schmancy restaurant and got the level of service from local pub? Expectations would not be met and you'd be disappointed, right?

Quality is Meeting Expectations

The point I'm making is that when expectations are met quality is met. That's right. When you expect a level of service, a predefined level of satisfaction, and then those expectations are met, quality has been fulfilled. If you've ever had the opportunity to read The Guide to the Project Management Body of Knowledge (PMBOK) you have my condolences. This book, in my opinion, reads like a toaster manual. Having said that, the PMBOK is often referred to as the Bible when it comes to project management. According the to PMBOK quality is defined as "the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs."

Whoop-tee-do. Did they get an attorney to write that?

In English, when it comes to project management, quality is the ability of the project to meet all of the project scope requirements - and the implied needs of the project scope. Let me give you an example: you and I are building a brick house and we've approved all of the blueprints, the design documents, the landscaping, and everything else down to the type of door knobs and bathtub drains.

The builder builds the foundation, frames the house, and has the mason lay the bricks. On our first inspection, however, we notice that the mason has done something terrible. Each brick, on one side, is embossed with "Chicago Brick Company." Our mason has consistently laid the bricks with the text "Chicago Brick Company" facing out. Our beautiful brick house looks great from a distance, but up close we're one big ad for the Chicago Brick Company. Say it with me: Greeaaat.

Of course we object, but the mason and the architect counter-object because we never stated that the text should face inward, not outward. Besides, they have built the house exactly to our design documents and blue prints down to the doorknobs and bathtub drains, so what's the problem?

The problem is that the house, while it satisfied stated objectives, did not meet implied objectives. Who wants to look at "Chicago Brick Company" a few million times? Now attorneys have to get involved and I'd rather eat worms than deal with attorneys. (Wow! two cracks on attorneys in one article - here come the lawsuits!)

Quality Is Not an Accident

In project management, as with most things in life, quality is planned in, not inspected in. Quality, and the expectations for acceptance, must be defined up front. I know, I know, this sounds great on paper. Let's have a real word moment, shall we? Here's a discussion I've had with stakeholders:

• Me: Hello, stakeholders, what do you want?
• Stakeholders: We want our software to do this, this, this, and this. And we need it to be really, really fast. And we need it yesterday around noon. And we've got $23.45 to pay for it, okay?
• Me: (after pulling my hair out, completing eighteen rounds of negotiations, and getting the stakeholders to define exactly what "this, this, and this" means): Now about this $23.45...
• Stakeholders: It's all the cash we have unless the lottery hits tonight.
• Me: The lottery isn't until tomorrow night, but even still, you've created a scope that's this big (I stretch my arms far apart like a Michael Jordan basketball pose) but your budget is only this big (I bring my index fingers close together like when I report on the puny size of my brother Sam's fish).
• Stakeholders: Hey, that's how big your brother Sam's fish was. Can we trim some of the scope to match a budget of $250,000?
• Me: Yes.

And then we discuss all of the objectives, design documents, and expectations for acceptance that'll make the customer happy. In short, we've got to know everything before we begin. The stakeholders and me, the project manager, have to define all the business that'll make them happy when the project is complete.

All metrics, such as throughout, data consistency, speed, and vague terms like reliable, good, super-duper good, and so on must be defined in hard metrics. We know what'll happen if we don't nail this stuff down, right? You'll get to the end of the project and the stakeholder will say, "Well, this is only super-good, we specifically said this had to be super-duper good. Sorry."

In addition to defining all of the project objectives the project manager has to determine how her project will live under the quality policy of her organisations. In some organisations the quality policy may be nice and vague, like "Quality is job done." Or "The customer is always right if they pay on time."

Other organisations subscribe to quality programs like Six Sigma, Lean Manufacturing, Kaizen Technologies, and ISO 9000 or 10000 programmes. In these systems the project manager must follow the quality expectations of the organisation to show improvements, measurements, and satisfaction.

All of the planning and prevention is really Quality Assurance (QA). QA is a management process that is focused on preventing a lack of quality from entering into projects, operations, and the organisation as a whole. QA is prevention-driven. It's a giant quality umbrella that all project managers must operate under. All project managers must map to QA specifications throughout the project. QA is an ongoing process that helps the project meet expectations.

QA and Knuckleheads

But doesn't QA cost cash? You betcha. We call this the "Cost of Quality." The Cost of Quality is the expense a project, or organisation, must incur to ensure that quality will exist within projects. Imagine that you're a project manager of an Oracle project. You've been assigned a team of knuckleheads that know nothing about Oracle. This crew will be your database administrators for this massive billion-dollar project that could make your career or send you back to the mailroom. Your project team, the knuckleheads, can't even spell DBA let alone contribute to your project. What should you do?

Train the knuckleheads.

Training is one cost of quality; if you don't train the project team then they won't be able to complete the work in the project. Okay, I admit, this is an extreme example, but I wanted you to see that lack of education can cause your project to fail.

Other costs of quality? Safety issues, OSHA issues, union compliance, adherence to regulations and standards, meeting project objectives, and any other expense the project must eat to ensure that project deliverables are accepted by the customer.

When a project cuts corners and doesn't pay for the cost of quality then the project, or organisation, will have to pay the cost of non-conformance. The cost of non-conformance are the monies spent to redo work, buy new materials for those that were wasted, refund customers their money, the loss of customers and sales, fines, and all the other negative things that can happen to an organisation when quality is not delivered. It's no fun. (Uh, I've heard).

Quality Control is Inspection

Alright, so all this planning is good, and it's even better when it all works, but how does a project manager know that project is meeting the quality expectations? You could wait until the very end of the project and see what the customer says, but that's a risky as blow drying your hair in the shower. What you need, what you must have, is quality control (QC).

QC is inspection-driven. QC requires the project manager and the project team to inspect the work that's been done to determine if the work results are in alignment with the stated and implied objectives of the project scope. And if they're not? Fix the freakin' problem.

QC is all about keeping mistakes out of the customers' hands. You and the project team must work diligently to ensure that all of the work is accurate, on-scope, and meets the objectives that customer has defined. And do it quickly. But QC takes time. It takes time to inspect the work. It takes time to redo the work. It takes time to check the work that's been redone. And time is rarely on the project manager's side.

And who's paying for all these inspections? Usually your project is. If we revisit our discussion on planning, the project manager must plan for time to inspect the work and monies for the inspection of the work. If all goes well (and when does all go well?) then there won't be a need for additional funds and time. When projects are under tight time and cost constraints it becomes paramount for the project team to do the work right the first time.

Have you ever wondered why there is always enough time to do the work right the second time? To me, there's nothing more aggravating than barking dogs while I'm trying to write articles (that's for my neighbour behind me - shut your dog up, please). I also find it aggravating, in the project management world, when we've got a fantastic plan on how to do the project work, we've got a fantastic plan on how to meet the quality objectives, and we've got a fantastic plan on how we'll follow-through with all of our promises - and then somebody chokes and turns in slop.

Now everybody wants to quote Steinbeck: "The best laid plans of mice and men often go astray." Don't you just love that? Well, take me out to the field and shoot me.

Now we're redoing work, spending more cash, wasting more time, and arguing about the literary consequences of writers that did or didn't drink too much. All-in-all, lack of quality hurts a project in more ways than one: time, cost, team morale, confidence from the customer, and on, and on.

Sometimes lack of quality causes a domino effect. Have you ever had quality issues that consumed the project team's time to correct? Of course you have. And then what happens? Your project team feels rushed to completed other assignments to make up for lost time, which usually creates more quality problems, which starts the process all over again.

It's always more cost effective, more time effective, and just more fun, to do the project work right the first time. Fun? What I am thinking? This is project management; there ain't no stinkin' fun.

There are plenty of tools a project manager can use to assist with quality control. Here are three for now:

• Ishikawa Diagrams: these are also known as cause-and-effect diagrams and fishbones, but Ishikawa sounds brainier. The point of these diagrams, regardless of the nomenclature, is to facilitate a conversation on why causes and contributing to a problem.
• Pareto Chart: ever hear that 80 percent of your income comes from 20 percent of your customers? Or that 80 percent of your help desk problems come from 20 percent of your employees? That's the 80/20 Principle and the Pareto chart shows the categories of failure within a system. Then we use 80 percent of our effort to attack the largest identified problems.
• Control Charts: A control chart really shows normal distribution and allows us to track trends and adjust our mean when we reach goals and need to set new quality goals. The point of a control chart is that we can track trends over time.

Verify the Scope and Cash the Cheque

QA and QC activities happen throughout the project. Remember QA is a management process that is prevention-driven, while QC is a project manager process that is inspection-driven. Now all of this is really good on paper and theory, but in the real world it comes down to the one person that matters most in any project: the customer.

Throughout the project the customer must participate in scope verification. Scope verification is the same process of QC: inspection. However, the difference is that QC is done before the customer, and scope verification is done with the customer. QC wants to keep mistakes out of the customers' hands, while scope verification allows the customer to say things like, "Yep, looks good." Or "I don't know what I'm looking at, but I believe you." Or, "You're standing too close and your breath smells like onions."

Project deliverables need to be inspected throughout the project - not just at the project's end. As projects move through phases, at major milestones, and finally at project completion scope verification must be performed to ensure that work is of quality and the project is in alignment with the customer's vision.

Quality, like it or not, must be planned, must be inspected, and then must meet the customer's objectives. Now, if you'll excuse me, I'm off to my local pub for a Reuben sandwich and a beer. Hopefully.

Developing a New Project Scorecard

By Sam Miller

Managers and project managers gauge the success of any project undertaken through a new project scorecard. In the development of this scorecard, relevant metrics will have to be pre-determined.

Most companies see the need to use scorecards in order to assess and measure how corporate efforts contribute to overall organisation objectives. These tools of measuring performance are deemed to be mandatory, especially with the implementation of new projects or tasks. Focus of corporate executives should not only be limited in scorecard development, but also in strategy implementation. Nevertheless, designing a scorecard that is most appropriate to an organisation is not an easy feat.

In designing a project scorecard, corporate executives should first ensure that operational plans implemented are consistent with the preferences and needs of the end clients. These plans as well as metrics identified should not contradict with each other. While in the process of project scoreboard development, corporate executives and managers are urged to follow the Balanced Scorecard management approach. This concept was introduced by David P. Norton and Robert S. Kaplan back in 1992.

This aimed at the assessment and evaluation of corporate activities in terms of overall strategy and vision. The use of the Balanced Scorecard approach involves focus on four sections, or perspectives as they are also called. These perspectives include the customer perspective, learning and growth perspective, internal business processes perspective and financial perspective. In the process of scoreboard design, five to six metrics are identified for each of the perspectives. There should be justification as to the choice of these selected metrics. The data derived from these metrics should be able to help managers understand how a new project is performing.

Moreover, these will also help them translate strategies into appropriate actions. For these metrics to achieve their purpose, they should be simple, measurable, and very straightforward. They should become a common language by which all members of the organisation should base their actions. Before deciding what metrics to use for performance assessment, managers and corporate executives should be able to identify the problem and company objectives. Prospective metrics to be used should be brainstormed and individually appraised.

Often times, managers have problems determining whether a new project that recently ended can be considered a success or a failure. With a project scorecard, managers should be able to do this with ease through the metrics identified, which would then function as a criteria or indicator for success. So, if the metrics show poor numbers then, the project is considered a failure.

Aside from using a new project scorecard, project assessment could also be done by asking for the opinion of the project client or sponsor. His reply should be based on whether or not initial objectives are achieved. The drawback of this approach is the fact that his response could only be one of two, "no" or "yes." There is no middle ground for this approach resulting to less reliability. By using multiple success criteria through a project scorecard approach, project managers will be able to effectively define and determine project success or failure.

A Project Management Primer: Basic Principles - Scope Triangle

By Nick Jenkins

Called the "Scope Triangle" or the "Quality Triangle" this shows the trade-offs inherent in any project.

The triangle illustrates the relationship between three primary forces in a project. Time is the available time to deliver the project, cost represents the amount of money or resources available and quality represents the fit-to-purpose that the project must achieve to be a success.

The normal situation is that one of these factors is fixed and the other two will vary in inverse proportion to each other. For example time is often fixed and the quality of the end product will depend on the cost or resources available. Similarly if you are working to a fixed level of quality then the cost of the project will largely be dependent upon the time available (if you have longer you can do it with fewer people).

The astute reader will be wondering what happens when two of the points are fixed. This is when it really gets interesting. Normally this occurs when costs are fixed and there is a definite deadline for delivery, an all too familiar set of circumstances. Then, if the scope starts to creep you are left with only one choice - cut functionality. This more common than you might think, in fact its more common than not!

Cutting functionality may seem a drastic measure, but an experienced project manager will happily whittle away functionality as if they were peeling a potato. As long as the core requirements remain, everything will be fine. Additional functionality can always go into "the next release," but if you don't deliver the core functionality, there won't be a next release.

A really experienced project manager might even pad his project with a little superfluous functionality that could be sacrificed when the crunch comes (but you didn't hear it from me!).

A phenomenon known as "scope creep" can be linked to the triangle too. Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope creep is inevitable since, early on, your project will be poorly defined and will need to evolve. A large amount of scope creep however can be disastrous.

When the scope starts to creep, new functionality must be added to cover the increased scope. This is represented by the quality arm of the triangle, representing the ability of the product to fulfil users' requirements. More requirements fulfilled = a better quality product.

In this situation you have three, and only three options :

1. Add time - delay the project to give you more time to add the functionality
2. Add cost - recruit, hire or acquire more people to do the extra work
3. Cut quality - trade off some non-essential requirements for the new requirements

If the art of management lies in making decisions, then the art of project management lies in making decisions quickly! When faced with scope creep you cannot ignore it. You need to tackle it in one of the ways described above (more later) and the sooner the better. Delaying raises the risk of your project failing.

A poor project manager will see the scope triangle as a strait-jacket by which their project is irrevocably constrained. A better project manager will make better use of one or more of the axes and will shift the emphasis in the project to one of the other axes. The best project managers will juggle all three like hot potatoes and will make decisions every day which effectively trade-off time vs quality vs resources.

Controlling Project Costs Through Interactive Planning

By Mark A. Borodynko

If time is money, keeping a project on budget requires utilising the project's estimate, schedule, cost forecasting, and earned value systems interactively.

We have all heard it discussed one way or another - time and money equate with one another. Yet, in our specialised world where we need to keep our budgets lean, we have almost forgotten that we actually need to spend money selectively in order to save money.

The tendency is to reduce the budget for those who are guarding your money and schedule - the planning/scheduling and cost-control individuals. I've seen some companies assign this task to the project manager. When this occurs, a red flag should be raised, because it means that the control of the budget and schedule is only being done on a part-time basis. Part-time project controls equals inferior project results.

Having project controls alone is not enough to ensure your project will remain on budget and on schedule. So, how can you accomplish this on fast track, value engineered projects?

I have observed that successful project leaders have made a paradigm shift in their thinking as compared to the more traditional school of thought I call "thinking in a silo." The silo thinking process waits and holds off the construction management team until the detailed design documents are about to start or, even worse, when the detailed design documents are completed. This is too late in the project's life cycle. At this stage, there is a preliminary estimate and schedule developed. But because the estimate and schedule are based on preliminary engineering, it could be a false budget estimate and schedule put together at the completion of preliminary engineering by the engineer and owner, rather than by the entire team. To make matters worse, the construction start date is now set by the forecast receipt dates reflected on this preliminary schedule.

Therefore, the aforementioned paradigm shift in thinking needs to be applied earlier, during the preconstruction phase (during preliminary engineering). It covers the following three principles and applies them interactively to the estimate, schedule, and earned value systems.

Principle 1 - The Team

Assemble the right team, early in the project. Kick off the project with a team-building meeting. In order to do this, of course, you need to assemble the right team. The team should consist of key individuals representing the owner, architect/engineer, and construction manager. The scope of the project is drilled into these individuals, so when the project is being engineered, the costs to build and commission the facility are all interactively related and shown on the estimate and schedule dynamically. This principle insures that an agreed to budget and scope is established and all key team members are aware of how the project arrived at the estimate. Have you ever been in a final estimate review meeting and heard someone say, "How did we get to this number?"

Principle 2 - Planning for Problems

Acknowledge the project will have problems and plan for contingencies. This is so basic, it's never discussed. The project will have problems; so if that is true, let's start looking for them now. The earlier we find them, the bigger the influence can be applied at the lowest cost. The team needs to be trained to stop being defensive or prideful. Remember - the estimate and schedule was developed by the team, not just you or the estimator or the planner.

How do you identify these problems? Let's use the tools that we have. The first tool is the cost report, which takes the estimate and converts it into a coded budget where the committed and expended dollars and hours are reported. But what are the forecasted dollars at completion and how does that compare to the team's budget? Should there be a difference, you have identified a potential cost problem early and if you're not "on the defensive," you can rectify the problem.

Since cost and schedule are interrelated, we also need to look at our second tool - the schedule - as a forecasting tool and ensure we use the schedule as a true critical path method (CPM) of scheduling so we can forecast where the project will end up in time and not just report what activities were completed.

The third tool to identify problems should be the use of an earned value system that is used for both the architect/engineering firm and the construction manager's measurement of percent complete progress. What works best for the architect/engineer is taking the engineering budget and converting it into hours by an average rate for the particular discipline, then assigning the budget hours to the disciplines drawing and specification types. Most importantly, a series of "check points" that can be validated should be used to ensure that overstating of progress does not occur. The construction management earned value system should relate to quantities that need to be installed. The key here is to keep it simple and measurable at the appropriate level customised for the type of project. We are looking to forecast potential problems that we can drill down into when identified, not keep track of every piece of formwork that is installed.

These three tools, when used interactively for forecasting, will reflect the team's forecast finish date and cost. Should the result be a problem, then you've identified it and, applying your professional expertise, you have time to correct it. The alternative is the "Ostrich" mentality to project management; most of us know what happens when we keep our heads buried in the sand and take the defensive approach. Let's stop being defensive - you're slowing down the team that's heading for the goal.

Principle 3 - Stop "Silo Thinking"

We need to graduate from our specialised silo thinking into a more of a proactive community approach. What you do on the project directly affects the community or, in this case, the project, both in time and money. This is always most evident at the start of a project. In the beginning, everyone has their own plans for how and when things need to get done. Most of the plans are genuine and meaningful. However, it reminds me of someone dropping a quill full of arrows onto the ground that are going in many different directions. A project needs to have all these arrows, or plans, identified and positioned so that they are all headed in the same direction. I recommend doing this early in the project with the key members of the team, in what I call an "interactive planning session."

This planning session will identify the owner's critical milestones and the dates that they need to be completed. It will establish the necessary tasks that need to be accomplished in order to support these key milestones and will form the baseline for the entire project's master schedule. The major tasks are identified interactively by having the team place their key tasks on one comprehensive timeline. These key tasks cover all phases of the project and include: preliminary engineering; various bid packages for detailed engineering; purchase and delivery of major equipment and procurement of long lead material such as structural steel; funding requirements of the owner; permitting and environmental requirements; major subcontract procurement strategy; demolition, if required; major construction activities; major tie-ins; and commissioning/validation, depending on the project. This intense effort identifies problems early and gives the team an opportunity to get realigned, if necessary. It turns individual plans into the project master plan and shows the interdependence of each task to the other.

Ensuring that projects stay on budget does not happen by looking at what is spent or invoiced to date. The answer lies with changing our current thinking. A project's budget rests upon a three-legged stool - each individual leg consists of the estimate, cost engineering/earned value, and planning/scheduling systems. But all three need to be working together to support the budget. If one is missing, then the budget is in jeopardy. Therefore, a team needs to ensure they embrace and incorporate the project controls mission statement into its culture and "utilise an integrated application of estimating, cost engineering/earned value, and planning/scheduling with the correct level of software in support of project management."

Then the project must go the extra mile and truly transform itself into a team effort. This team can change the fulcrum of the project. With a team attitude, defences come down and team members can look for problems to solve, which in turn lets the team run more efficiently and effectively towards the goal of an on-time and on-budget project. Through interactive planning, and the team working together toward one goal, there is an increased awareness that what an individual team member does has a direct affect on other team members and their downstream tasks.

This integration of project controls tools applied by the project control professionals, combined with an early paradigm shift, will ensure projects are completed on time and within budget. You may even end up with some contingency.

Step-by-Step Beginners Guide to Project Management

By Lee Iwan

In my experience, projects must; actively involve all the group members, have excellent communication and access to project information, have a shared desired outcome, have sPost Optionspecific dates for completion of tasks, and have all the required tools (when needed) in order to finish.

If there is no enthusiasm in the group, your project is dead or doomed to be incredibly dull and tedious.

It's all about very simple questions; what, where, who, how, when, how much, and fixing specific dates and commitments from the group members. The key to success is the leadership and maintaining the level of enthusiasm of the group members, mixed with the correct resources and tools available on time, and a shared sense of urgency in order to bring the project to completion.

Here is a simple outline that may help in organising the project and the participants.

1. Determine the objective and specific desired outcome. Write it down.
2. Identify and organise the people who might be interested or are required in order to bring the project to completion. Ask them to participate, and comment on their level of enthusiasm or belief that the project can or will be successful.
3. Identify a project leader and co-ordinator, this should be accepted by all involved in the project. No consensus, keep trying.
4. Begin "brainstorming" and create scenarios on how to achieve the desired outcome (this may have be broken down into sub-tasks). Make a date when all this creative thinking will be finished and a written draft can be printed and shared.
5. Identify factors that influence or limit the project that are beyond your control (global economic forces, natural disasters, competition, etc.) and factors that are in your control (capital invested, personnel, prices, etc.). Identify the risks or warning flags that might surface. Write this down.
6. Determine and identify the tools (capital, equipment, machinery), the people (administration, sales, suppliers, customers), and the time required to complete the objectives. Write this down.
7. Organise the people involved in the project. Review the proposed project, the factors of influence, the tools, people and time. Determine the best path, tools, time frame, and write it down.
8. Organise the tasks and sub-tasks in chronological order. Write it down.
9. Ask each participant if they are committed to participating in the project, completing their tasks on time and reaching the final outcome. If there is no commitment, find out why and resolve.
10. Develop a list of initial actions and outcomes that must be started and completed. Identify the responsible parties and dates. Write it down.
11. Request specific (realistic) dates for the completion of tasks, sub-tasks and objectives. Write it down.
12. The leader must follow-up on all dates and compromises. Make this information public to all others involved in the project. Communicate all deliveries of sub-tasks, or lack of delivery with the group.
13. Make certain that the group knows the status of the project at all times, everyone should either be waiting for information or the outcome of an ongoing activity, or actively working on obtaining information or finalising an activity.
14. If a group member is unable or unwilling to finish tasks on time, discover why and take immediate action to support or replace the member.
15. For any major problems or setbacks, get the group together to work out new scenarios and dates of completion.
16. Celebrate the big milestones and victories.

How to Keep a Design Project Moving

By Brad Squires

It happens all too frequently. Everyone read the Creative Brief and gave their sign-off. The design team was selected because they had the most experience in your industry. The project schedule had plenty of padding built into it. But your web or graphic design project is nowhere close to final and you're a month past the deadline. How does this happen? Following are seven common causes for a design project to get held up, and suggestions to help you meet your deadline.

1. The Project Lacked a Goal

It is surprising how many web sites, brochures, and marketing campaigns are completed without first deciding upon the goals of the project. Ask yourself this question: "What do I want my audience to do when they see/read/receive this piece?" Without knowing the answer to this question, your project is at risk of repeated redesigns as it succumbs to the aesthetic opinions of all who give their feedback. Make sure everyone on the team has a clear vision of the goal, and help them to measure comments and feedback against this known objective. As Wayne Gretzky says, "A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be."

2. The Decision-Makers Were Left Out of the Decision

It can be very disheartening to have your final design ready to go to print only to have it pulled by the company president when he sees it for the first time. At the beginning of every project, make a point to conduct stakeholder analysis. Spend time with your stakeholders and find out what their hopes are for this project. Stakeholders can contribute expert knowledge to the project or can offer their political or commercial endorsement, which can greatly enhance your outcome.

3. Skimping on Exploration

A crucial component in any design process is exploration. This is the time when many many many ideas are generated and explored for their worthiness. Skimping on this step in order to rush the project along can get you into trouble by leading you too far in one direction just to learn that it's not working. Far better to explore many different options while they are still in the rough stage before deciding on a direction to fully develop.

4. The Review Process was Prohibitive

If the success of your project requires you to get 14 different middle-managers to all agree on a design by next Monday, you may be in trouble. If your project does require sign-off from many department heads, which can often be the case if your campaign will span several marketing channels, it is crucial that you build more room into your project schedule. Show stakeholders the respect that they deserve by allowing them enough time to provide thorough and well-reasoned feedback. By doing so, you are enhancing your chances of success - not only for this project, but future projects also as you'll enjoy stronger relationships with the stakeholders you treated so respectfully.

5. The Feedback Was Not Useful

The objective of iterative design reviews is to narrow in on the appropriate solution, using the decisions of one meeting to improve the breadth, depth or fidelity of the solution for the next meeting. One common affliction in the world of design, which David Cronin has called the Revision Death Spiral, occurs when designs are repeatedly revised without any progress toward a coherent solution. The symptoms of this are easy to recognise: an initial visual design direction review where the client "doesn't like" any of the proposed approaches; or subsequent meetings where the client decides that the currently chosen path should be scrapped in favor of a previously abandoned path.

The blame cannot be placed entirely on the heads of the client. Although clients will tell you that they'll "know it when they see it," it is rare that a client is sufficiently knowledgeable about visual design to articulate why they feel that a proposed solution or approach is not working. It is the responsibility of the design team to make sure they are getting the type of feedback they need to allow them to move the design closer to the solution. Asking the right questions, showing a progression of designs, and keeping the project objectives close to the focus of the discussion are tools that effective design teams use to keep a project moving toward success.

6. The Team Was Not Engaged

Your team is the most important resource you have available and their enthusiastic contribution will make or break your project. Look after them and make sure the team operates as a unit and not as a collection of individuals. The leader's roll is to create an environment which allows each team member to do his or her best work. Without encouragement, clear communications, trust, and ensuring that each person not only understands their role, but has a clear picture of success, the project will move sluggishly toward an uninspired conclusion. Create a milieu where criticism is recognised as valuable for improvement, taking inspired risks is rewarded and mistakes are not punished and you'll have a fertile climate for innovation.

7. Failing to Estimate Time Accurately

Habitually underestimating the time required to carry out certain tasks within a project can have a snow-ball effect within an organisation. Time estimates drive the setting of deadlines for delivery of projects. If a time requirement is grossly underestimated, the deadline gets missed. If this becomes a pattern, deadlines begin to lose meaning and peoples' assessments of your reliability will also be affected.

The ability to make accurate estimations of the time required to implement a project comes with experience and training. The first step towards making good time estimates is to fully understand the problem to be solved. Pay attention to the complexity of each project and allow time for internal meetings, other high priority tasks, holidays and sickness and so on. By improving your skills and providing accurate time estimations, the deadlines you set will command greater respect. When this happens, your team will be prepared to respond when it really is crunch time.

Tips for Project Management Success

By Andrew Winthorp

Bringing projects in on time and on budget is always a challenge. With the competing demands for labour and capital, projects have many internal and external forces that can contribute to a derailment. It takes a strong sense of direction, efficiency and leadership to keep the project on track. The following guidelines are some helpful tips that every project manager can use at one time or another.

1. Always take the extra time upfront to make sure that the business case has been adequately defined. Often, commercial demands desire to deliver a quick project outcome. Whilst expediting, the project should be firmly part of the agenda, taking the extra time upfront can pay long-term dividends. When projects are rushed the functional purpose of the project is often compromised and important details get overlooked. As the project manager it is important that you steer the client towards doing the necessary due diligence to ensure you have a watertight business case. In the event that the project is deficient in some way, you may be liable to take the blame if important details are overlooked. Costly damage control measures can send the project off course, result in budget blowouts and cause client resentment. Project managers need to have the foresight to take charge upfront and demand that projects are subject to proper due diligence prior to commencement.
2. Always build some contingency into the schedule and the budget. Doing so will give you greater scope to move in the event that contingent actions or adjustments become necessary. If you get pushed for time, you can allocate extra resources as part of your contingency budget. Although profitability may be slightly compromised, a positive project outcome is much more desirable than having to put out fires or explain to management why adequate checks and balances were not put in place.
3. Make use of software reporting capabilities to run regular reports for performance improvement. You will be surprised how much feedback reports can provide if you take the time to set them up. Process improvements and superior resource allocation all contribute to an increase in productivity and a reduction in costs. Ultimately this affects the bottom line. A good project manager strives for continual improvement.
4. Take time to build a good relationship with staff and team members. Successful project managers need to know how to get the best from their staff. A good leader builds respect and this respect transfers to project success. Often, when extra effort is required, if you have taken the time to build respect, team members will respond when the challenge arises.

These four tips have stood the test of time. You should keep them in mind, think about them and apply them to your circumstance. You might be surprised, if you contemplate these suggestions how you discover new insights that lead to greater project success!

Project Management As it Ought to Be

By Brian Krichbaum

Most of us are beyond the point where we believe that successful project management can be accomplished by following a formula or merely using the right system. It's not that the tools are unimportant, or that the systems don't work, because they do. However, the systems and the software only make the job easier; they aren't the elements of success.

Great ideas aren't great products until they can be made and sold at a profit. Solid project execution can help bring this about.

1. Pick and empower the right person to be your project leader

The project manager needs to be one of the best managers in the company and picked at the onset of the project. After all, they have a difficult job. They must manage diverse teams with members who all have "real" bosses elsewhere in the company. When picking someone to be a project manager, keep these requirements in mind:

• Project managers need detailed cross functional knowledge.
  The development, production, procurement and quality systems at your firm are complicated. It isn't necessary for project leaders to have worked in all these functional areas, but the more the better. Understanding the workings of these areas is critical to prevent the leader from being bamboozled by the functional experts. Detailed, first hand knowledge of the product, design and engineering systems, quality standards, manufacturing technologies and the politics of your company is mandatory.
• Technical projects should be led by technical people.
  Don't expect a leader of product development team to be successful if they can't speak the language of the technical team. A procurement specialist or a logistics expert is unlikely to be able to fully understand the subtleties of the design and specification process; and they will have difficulty separating the critical requirements from the fluff. Engineers have disdain for those who are not technically sophisticated and can unintentionally intimidate others with the knowledge of technology; project managers must be able to ask tough questions to be successful. Not all projects are technical in nature. Redesigning a service offering or revamping marketing plan projects should be led by those who are experts in these fields.
• Project managers must have superior organisational skills.
  The great engineer who can never find the spec book or retrieve the latest test results probably isn't a good candidate. The management of project is an exceptionally detailed endeavour - pick someone who loves the detail.
• Make sure that your project managers are great problems solvers.
  A project is nothing if not an exercise in solving problem after problem; make sure your leader knows how to deal with these issues.

You will have to develop your own project leaders. Given the range of skills and experience required, you probably aren't going to find the "right" person for the job. Pick someone with most of the skills; start by giving them the experiences needed and groom them until they are ready.

The right project manager will use the systems you have developed seamlessly, and it will sometimes look easy. The wrong project manager will take the greatest system and make it a toilsome nightmare, spending weeks preparing for routine reviews, and delivering substandard results.

2. Make sure that constraints for the project are completely defined

The bane of project management is changing or "updating" constraints once the project starts. Many of these changes are in fact oversights that should have been identified early in the process. Without solid definition of all constraints, it is too easy for significant changes to be made late in the process. Take time before the design process starts to get the definition right.

The constraints, or Scope of Work (SOW), have several elements. Customer constraints lead the list, but manufacturing limitations, market introduction timing, aesthetic concerns, governmental or industry regulations also add to the constraints. In many projects, this process of mapping the constraints is overlooked or underemphasised. Here are some simple rules to keep in mind which may help you identify all the constraints:

• Before work begins, take time to define responsibility for each element of the project. This is especially important when collaborating with outside firms as partners, suppliers, or customers. For example, who has primary and support responsibility for designing, testing, validating, and manufacturing the part?
• Remember: Assumptions are only bad if you don't document them. Make sure that they are all documented.
• Recognise: Projects always involve change. Be prepared by deciding in advance how SOW changes will be handled. Do approval authorities need to be established? SOW management makes or breaks projects. When the sales department or customer decides that the part needs to be stainless steel instead of plastic - the scope of the project has changed and the parameters need to be updated.

Learn this lesson well. It could save you millions. During one of the major development projects I managed, the customer constantly asked for new or upgraded features to be added to the scope. But we had a detailed, approved SOW, and an effective SOW change management system. At the conclusion of the programme, when the customer's procurement team was trying to pull cost from the project, we were completely covered. All of the SOW changes were approved and we were able to improve our margins.

3. Utilise pull planning rather than task planning approaches

Two difficulties with project management are keeping a project on schedule and on budget. Failures to meet requirements in these areas have resulted in an over reaction in the level of detail put into early project plans. Nice little catch phrases like "He didn't plan to fail, he just failed to plan" distort the realities of the situation.

Task based plans focus on the work that needs to be done and how long it is expected to take to complete this work. In the more complicated models, we are encouraged to estimate the minimum time, the expected time, and the most likely time each individual task or subtask will take. The more detailed the plans, it is argued, the more predictable the results. The job of the project manager is to make sure that the tasks are being completed in accordance with the plan.

But task based plans break down and subsequently lead to micro-management. The break-downs are seldom because we don't keep up with the schedule. It is more likely that tasks were omitted from the plan or the resources required were greatly underestimated. In short, the plan becomes a substitute for responsibility and excuses like "We did it per the plan, it just didn't work out" begin to be heard.

Ironically, the response to these issues is to create more and more detailed plans, which are likely to conclude with similar failures, because the real causes of our project failures have not been addressed.

Pull planning offers a dramatically different approach. Instead of focusing on the tasks, or the work, it focuses on the desired results. For example, when planning a validation test, a pull plan defines the objectives and the timing of the test. It defines the design release levels and the types of tooling to be used. The plan specifies the confidence that the team needs to have in the results and the methods or particular tests are to be performed. If there are any secondary considerations or objectives, such as using the build event as a learning opportunity for production associates, these are also listed. The consolidation of these plans for each controlling event becomes the project plan. The project team pulls and manages necessary resources to deliver the results for the controlling events as the project proceeds.

Even with a project using pull planning methodologies, there will be times when task planning is necessary. However, they are short-term, specific events on which the team is currently focused. For example, if a prototype event needs completion to facilitate a validation test, then release of Purchase Orders, delivery of components and planning of lab resources must be done on a micro level and in great detail. It is necessary to the success of the project.

But don't try doing it months in advance. There are just too many unknowns to make it valuable. Instead, team members will become frustrated as the plans decompose. Project leaders will eventually give up and "re-plan" the project.

Don't waste your time building a Microsoft Project Plan which defines exactly when specific tasks need to be accomplished. It is impossible to comprehend at the project initiation all the tasks that will be required to complete the project. Focus instead on deliverables and results required at specific, predetermined milestones. Then make sure you have a project team with the expertise, the knowledge, the responsibility and the authority to determine when and how to complete the work to ensure successful completion of the project.

4. Communicate, Communicate, Communicate!

Project management is solely about communications. The project leader that does not communicate well will fail. There must be communication within the team about responsibilities, targets, and requirements.

Additionally the team must communicate with management, customers and suppliers. When people on the team aren't performing to expectation - or when they are performing well above them - their managers need to know. If there are issues that are threatening success, or newly found opportunities, management must know.

When a roadblock appears due to technical issues, reach out to experts and other teams. It is likely that someone has had experiences that will ease the path to the solution. When innovative ideas are discovered, trumpet these successes.

Good communication skills cannot be learned soon enough. During my first experience as a programme manager, we were experiencing a significant issue that was a result of poor design decisions. In order to save face, I decided to keep the issue under wraps "for a couple of days" until we could solve it. Fortunately, after two weeks, with the problem still looming, a team member spilled the beans, and management became fully aware of the problem. I learned quickly that the issue itself was of less importance than the sharing of all information.

Pride or fear cannot be allowed to prevent communication within teams, with management or with other teams. Communication is the primary purpose of project management - don't neglect it.

5. Develop your own New Product Development System

In the business climate today, the requirements for product development are extensive; environmental regulations or recycling rules mandated by the government, requirements for durability tests set by the customer, building or painting permits required by local authorities, as well as internal corporate requirements... and the list goes on. If you are part of the automotive industry there are APQP and TS 16949 requirements. It is too much for anyone to remember.

Teams need checklists to ensure that the critical developmental tasks aren't being overlooked. It isn't good enough to rely on the memory of your project team, management team, or executive team to ensure that everything gets done. Define the requirements, plan the programmes around them, then check and report results against the requirements. Use this system as a tool for success, not just a series of tasks that have to be completed.

Formalise the system; allow it to change and grow as it is used - but don't try to shortcut the process.

6. The executive team must stay involved.

These projects are the future of the business. As such, they merit the attention of the executive team. Stay involved in the projects to ensure things are going as planned.

Good projects have mechanisms built in to keep top management involved. Periodic reviews to provide face to face interactions between team members and executives are key to project success. Such reviews need to be conducted often; at least monthly. Don't combine the reviews with other staff meetings or strategy sessions - it sends the wrong message. Specific purposes for these monthly reviews include:

• Reporting project status relative to the project plan
• Identifying major concerns, customer complaints, or obstacles to success documented
• Reporting on changes to the project plan; SOW changes or changes to programme risk
• Update financial projections
• Allowing for direct, two way communications between executive team and the project team

Related experiences of the executives can often be beneficial to the project teams; the review provides the regular opportunity for this type of interface. Conversely, the project team will have the opportunity to directly report obstacles, roadblocks, or other difficulties.

New Product Development Systems (NPDS) establish regular Phase or Gate Reviews to provide formal approval of projects before proceeding to the next phase. The dates for these reviews need to be established during the project planning phase: the review requirements are established by the NPDS itself. These reviews are deep dives into the status of the project and are a critical part of the checks and balances that are required to uncover potential issues to project success.

But these reviews are not enough. Involvement of the executive team needs more consistency than can be provided during these brief, formal reviews. The project team should be supported by informal and frequent visits of the executives. Review the work product of the project team. If the team is in the planning phase; review and comment on the plans. Review the statement of requirements documents - make sure that the definitions are what you want up front. Remember, this is your future business.

So, what are you waiting for? If you haven't developed a NPDS, or if you aren't satisfied with the one you are using - start working on the new one. If you don't have a regimen for developing project managers, then why not start today. You will be glad you did when it's time to start the next project.

Flexible Project Management

By Alex Tylee-Birdsall

From the point of view of an outside observer it would appear that every project is doomed to be late, over budget or both. For large public construction projects in the UK such as the Millennium Dome, Wembley Stadium and more recently the London Underground refit, this would truly appear to be the case.

Even on a smaller scale many product development projects tend be misguided in what they will achieve within the planned time frame. There are normally a number of stock excuses for such a failing. These can range from "there was an unexpected change made by the customer", "we underestimated the amount of time required" or even "we didn't understand the risks involved."

In the arena of customer / supplier projects there seems to be an increasing trend to win the project and then worry about how to deliver within the cost, timing and quality later. This normally results in compromised delivery for the customer or sometimes financial losses to the supplier.

In a study by TBC (Tylee-Birdsall & Co) it was determined using the value mapping procedure that most technical design projects could theoretically be completed in half the time if they were managed perfectly and there was no rework required. If we therefore assume that most projects are 50% efficient we can easily bring this up to 80% or even higher if methods to reduce rework and delays were put in place.

Most project management training courses concentrate on time and risk management. This results in well developed timing plans and generally not so well thought out risk management plans. There are project managers who will try anything to cling on to the timing plan they developed at the start of the project whilst everything else falls apart around them.

So where should you start? Well everything starts with the customer who benefits from the end result of the project. Make sure you understand fully the customer's expectations for the project. If the project is internal research then make sure you know who all the stakeholders are and find out their expectations. You must also be prepared for expectations to change.

Any project essentially applies a process, or number of processes, to turn a set of data and/or materials into a final product or products. At each stage different products are created. Therefore a product approach to managing the project can be adopted which is comparable to a manufacturing process. The difference to a manufacturing process is that each project is different. You do not get the opportunity to apply the full project process more than once and therefore it cannot be developed in the same way as a manufacturing process.

This approach is called "product based planning" and is an integral part of methodologies such as PRINCE2 (PRojects IN Controlled Environments). One thing that must be remembered with such a method is that it must remain flexible and allow for change in the project. Change always happens and you must plan to accommodate it.

Once you know what your different product stages are you can then start to look at the tasks required to move from one product to the next and begin to pull together a timing plan. The initial timing plan and tasks list should be viewed as one possible route to a destination. You will need a good vision of the road ahead in order to change the route and stay on track. The majority of a project manager's time should be spent assessing risks and planning contingencies. A good project manager who has a good understanding of customer expectations will have a good idea what problems or changes may be encountered and will already have plans in place. They will be the least busy person in the team. A project manager who spends all of their time fire fighting problems has missed a step in their planning and will always be busy at the frontline.

There are many risk management methods that can be used. It is suggested a project manager uses the method they are most comfortable with. The objective is to determine issues before they occur or to avoid them completely. The problem with most risk management systems is that the project manager will carry out a half hearted risk assessment at the start of the project and then never revisit it. If you make the risk assessment your own process then you are more likely to follow it.

PRINCE2 has already been mentioned and this provides a sound methodology for achieving much of what has been discussed. However the method should not be followed blindly or rigidly, it only provides a framework and not a set of rules. Good sense, good planning and flexibility should always be part of the project manager's toolkit.

There are two good analogies that can be used for project management which you should bear in mind:

1. Driving from A to B. Generally when driving somewhere you will plan the route you will take in advance. You will also have a good idea of how long it will take you to get to your destination. You would certainly ensure that you had enough fuel to get to your destination and that your car was in good condition and had been serviced regularly. As a further contingency you would also have breakdown recovery assistance. A further level of planning would be to research the location of any roadworks or where the accident black spots are. You could then plan alternative routes to get around these problem areas if required.
2. Chess. The game of chess is very similar to the requirements of project management. You need to plan ahead in order to win. If you play a purely reactive game you are extremely likely to lose.

People, Process, and Predicting Project Success

By Johanna Rothman

Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people can overcome bad process to deliver a good product.

Bad management, management incapable of understanding how to remove obstacles or how to see the project state, can trump good people and good process. Management that doesn't help is better than management that actually hurts a project. (I once worked for a manager who insisted on calling my customer. Every time he did, he created a crisis I had to resolve. I ended up spending about 50% of my time managing my manager, with the rest left over for the customer and the project. Luckily, the project staff were great, so I didn't have to pay too much attention to them. That manager's actions cost us months in extra project time. But we finally delivered - less than we could have and much longer than it should have taken.)

Good process helps even out the differences in capability among developers. In "Peopleware", DeMarco and Lister show that in their Coding War Games, there was a huge range in capability. Quoting from page 46, "The best performance was 2.1 times better than the average. The half about the median outperformed the half below the median by 1.9 to 1." When you define and use a good process (reasonable lifecycle and practice for your particular project and context), you can reduce the variation in developer capability, bringing the people originally below the median up closer to the performance of those above the median. But if people don't have the functional skills and domain expertise, they can't use the process the perform well. And, bad management can trump a reasonable process anytime.

So when I predict project success, I don't assume people, process, or management is the one key to success. I look to make sure the project hasn't already shot itself with inadequately-trained people, bad management, or bad process. Then I look for an adaptable project. Here are some things I look for:

• Before the project, does the project manager have the ability to select the people for the project with appropriate functional skills and domain expertise? If the project manager doesn't know enough to select the people, does someone? Are people available when they are needed?
• Once the project starts, are people added to the project as needed? Delays in adding people delay the project.
• Is the planning iterative? Any project worth doing has risk associated with it. Planning the entire project in detail is a waste of time and does the project a disservice. Preplanning in detail (especially with an electronic tool) suggests to management that the project will unfold in the planned way. Nope. The schedule is the one way the project will not occur. I look for plans to replan, to take advantage of project advances and to deal with project delays.
• Is everyone watching for defects? Are people cleaning up as they go? This can be refactoring designs or code, or as simple as cleaning up the lab or other common work area. The messier the environment is, the more likely the work product is to be messy. If everyone isn't watching for defects, it's harder to clean up the work products later. (Yes, for me, these are interrelated.)

These aren't the quantitative measurements I use as a project manager to know when the project will finish or how much rework we'll need; these are the qualitative measurements I use to see if there's any chance the project will succeed. I use the quantitative measurements to help the project stay on track or get back on track. I look for this evidence of adaptability and flexibility when trying to predict project success.

5 Tips for Successful Projects

By Matthew Sheaff

On a regular basis we are constantly reminded that an overwhelming majority of projects are completed over budget, past the desired deadline and outside the original scope. Best practice project management reminds us that if we successfully initiate, plan, execute and close out our projects - our metrics will illustrate greater results. However, there's more to project management than just a simple methodology. With this in mind, here are five simple tips for completing this challenging process and improving your project outcomes.

1. Know and Understand the Purpose of your Project

This first tip sounds simple. However, far too often I've gone into organisations or talked with project managers and asked them, "Why are you undertaking this project?" There answer is predictable - "Because so and so told me too." The ability to understand why your project is critical to your organisation's mission and how it fits into the overall strategic plan is a key component to its success. Being able to relate the success of your project with over all organisational goals and strategies is an easy way to increase team member dedication, morale and a sense of importance. Also, understanding the purpose of the project or hearing how it ties into the strategic plan shows executive level buy in for the project. Further, if a project team gets consistent senior level support, they are more likely to have the adequate resources they need to complete the project and thus successfully complete the initiative

2. Maintain a Clear Grasp on Reality

A lot of times, organisations take on major projects that get all stakeholders really excited and anxious. For example, building a new baseball ballpark or opening up an international office in London. In situations like this, it is very easy to let all the excitement and the emotions cloud judgment and thus it's hard to have clear, realistic expectations for budget, schedule or scope.

3. Make Sure Roles and Responsibilities are Clearly Defined

A football team is successful only when each member on the field successfully their specific responsibilities and strategies, so too in project management. Each stakeholder plays a specific role and key role in the overall management of the project. Defining each member's role and responsibility is one of the first steps for success. I've provided a chart of the basic roles and responsibilities of project stakeholders below.

Stakeholder	Responsibility
Project Manager	Manages project, creates project plans, creates various management plans related to the project, measures project performance, takes corrective action, controls project outcomes, manages project team and report project status
Project Sponsor	Executive who initiates and oversees the project. Serves as advisor to the project manager
Functional Managers	Responsible for completing project activities and producing deliverables
Customer	Provides project requirements. Approves project deliverables and verifies that they meet requirements
Project Team	Responsible for completing the activities of the project
Suppliers	Provide goods or services to assist project team in completing project

4. FULLY Utilise your Work Breakdown Structure (WBS)

The work breakdown structure represents the hierarchical view of the project, detailing out the major deliverables to be completed in a chronological and easy to view format. [Hint: create your WBS with post it notes on a flip chart or whiteboard to easily shift around deliverables and create the perfect flow for your project.] However, most project teams do not get total value out of their WBS. Not only is it used for completing estimates on the project schedule and duration but it is a great tool to assist in project cost estimating and the budget process. Since the project is broken down into smaller parts, it is more accurate and easier to budget by deliverable and then add those estimates up for a more accurate project budget proposal.

5. Project Management is Not a "Fire Extinguisher"

Out of the five tips that this article has described, this one is by far is the hardest for organisations to actually practice. Project Management is not a "fire extinguisher" for when the project is sinking faster than the Titanic. It's not the great panacea used to combat the faulty planning that was performed. Instead, project management is a concrete methodology that must be used organisation wide. Failure to use best practice project management in all organisation projects regardless of size and dollar value will only result in poor performance. Finally, project management is only as good as the people who execute it, and the people who execute it are the people who hear and learn about it. Demonstrate the value of project management to your senior level management and get them to buy into the methodology - that's the only way to guarantee improved and lasting results.

Avoiding Project Failure: It's Not Rocket Science

By Duncan Haughey, PMP

It is true that every project is unique; however the underlying causes of project failure are usually restricted to a few specific areas. Once we know what these are we can take steps to minimise the chance of problems in these areas and increase the likelihood of success.

Poor Project Initiation

The Problem:

This is probably the most common pitfall. Not initiating a project properly with sufficient time spent to define and agree the user requirements, create a realistic plan and gain buy-in from all of the stakeholders means you're almost certainly destined for problems.

The Solution:

Resist the temptation to start the project too early before it has been properly initiated. Don't allow the customer to push you into starting the work on the assumption that it will result in an earlier delivery. The reality is that poor initiation extends projects by causing rework, errors and omissions. Just say no when pushed and never start too early.

Weak Ongoing Project Management

The Problem:

It's no good doing a thorough job of planning and initiating a project if you don't manage it effectively to its conclusion. Typical problems here are scope creep, poor work-plan, lack of change control, poor communication and poor management of risks and issues.

The Solution:

1. Introduce a change control process and make everyone aware of it. Use it to ensure that the resources stay focused on delivering what is important
2. Practice exception reporting
3. Communicate on a regular basis with your sponsor and other key stakeholders
4. Update your plan regularly. If you don't intend to update the plan then it's not worth creating in the first place

Insufficient Resources

The Problem:

Not having the right amount of resource or indeed having the right amount with the wrong skill mix can be a cause of project failure.

The Solution:

Insist that management provide appropriate resources either from internal staff or if necessary by hiring some on a contract basis.

Lifecycle Problems

The Problem:

There are many occasions during the lifecycle of a project for issues that may lead to failure. Examples of these include:

• Failure to define the requirements clearly, resulting in expectations not being met
• Cutting edge or new technology that causes unforeseen problems
• A poor technical design preventing the solution from being changed or scaled in the future
• Poor change control allowing change requests to cause the project to drift
• Changing priorities diverting attention away from core work
• Poor testing leading to bugs and errors later in the project

The Solution:

All of these issues and many others should be considered at the start of the project. A good approach is to brainstorm the possible issues with your team or other project managers who have run similar projects. Some solutions for the examples above include:

• Employing a business analyst to draw out the user requirements and document them in a clear concise way
• Asking if it is necessary to use cutting edge technology or whether a more tried and tested solution would deliver all or most of the benefits
• Using the team to create the technical design, this way you have a far greater chance of something robust and scalable with the added bonus that everybody has a stake in making it succeed
• Agreeing a change control process with the customer before the project starts and sticking to it.
• Creating a weekly work-plan for the resources so they remain focused on the priorities and don't get side tracked.
• Putting together a test plan with test scenarios based on the user requirements and ensuring you have enough resource and user commitment to run them.

Managing Expectations

The Problem:

Often projects start on a high with a huge amount of optimism. During the project lifecycle expectations can inflate to an unreasonable degree well beyond the reality of what can be delivered.

The Solution:

It is the role of the project manager to manage expectations to a sensible level. One way to do this is to break projects down into smaller chunks or phases with frequent milestones. This way you manage expectations by making regular deliveries so the customer sees what they are getting. This approach ensures the project delivers to the customers' expectations by giving them early visibility of what you are building.

Don't become the casualty of a failed project, put measures in place that address these five key areas to help ensure your success. After all it's not Rocket Science!

Let Project Management Boost the Bottom-Line

By Michelle LaBrosse, PMP

The next time you hear the words "bottom-line" when you're sitting in the audience at a company meeting, don't roll your eyes. Instead, think about all the ways that you as a project manager can help to boost that bottom-line.

Top Five Project Management Bottom-Line Boosters

1. Develop clear and quantifiable goals. If a goal is murky and indistinguishable, how does anyone know when and if it's done? Don't hide behind a curtain of vagueness. Be clear and make it measurable because a wise woman once said, "What gets measured, gets done!"
2. Track time and pounds spent. When you can show your boss and your team exactly where you are both in terms of time allocated and actual pounds spent, you're speaking their language. Nothing makes upper management quiver more than not knowing where they are on a mission-critical project.
3. Meet deadlines and milestones. If your team is missing every single deadline and project milestone, there's generally a reason why. Don't accept this as normal. Do you have too many false deadlines in your company culture, so people no longer accept them as real? When you understand what impedes meeting deadlines, you can get answers that not only get your project back on track, but save your organisation time and money.
4. Unearth the hidden gems in your project agreement and documentation. Too many people mistake documentation as busy work instead of using it to get at its real value. When you close out a project, don't literally put it to bed. Instead, wake up and unearth all the gems inside it. Did you have enough resources allocated to this project? At what points did this project falter and why? What was behind the cost variance between our original budget and actual budget? If you don't capture the intelligence in your documentation, understand it and share it, you've missed a huge opportunity to make you and your team more productive, effective and efficient.
5. Create a consistent and standardised approach to project management. I know this seems like a no-brainer, but I see companies every day that expect their people to learn project management by osmosis. I know you've seen this too: "Let the new people shadow Gloria for a few days because she's a great project manager." This is a good start, but you can't have enterprise-wide impact from project management unless you have a consistent way of approaching project management. This is why the PMP certification has become important to many businesses and government. These organisations have started to see the value of having whole teams and whole departments - and even entire companies - working from the same body of knowledge.

Embrace the Bottom-Line

So, now you know what many project managers already use as their "secret sauce." The bottom-line is not just for accountants and executives. It's a sure fire way for project managers to show their value and make themselves a valuable player in financial discussion.