Technology Vendor Contracting: Breaking the Mould

By Timothy Nuckles

Commercial buyers of information technology products and services are locked into a self-defeating pattern of behaviour when it comes to negotiating contract terms and conditions with technology vendors, and it is time to move on to a better approach. Better technology vendor negotiations produce better contracts for a technology project, and better contracts produce better project outcomes. So, break the mould and move on to a better way of negotiating contract terms and conditions for your next technology project.

Vendor Contracts - Timing Is Everything

Let us assume that by now you have done a lot of planning and information gathering for your proposed technology project, you have completed a vendor selection process, and now it is time to document your deal with your chosen vendor.

At this stage in the technology procurement process, the most common practice, indeed the almost-universal practice, is to distribute the vendor's proposed contracts to your project team for review and comment. Then, as if by instinct, everyone starts looking for vendor bias in the contracts. No one has been given this specific directive. You simply assume and expect that everyone knows the drill. Folks on your project team begin striking certain biased provisions and scribbling notes about amending others. For sure, removing or limiting vendor bias in the contracts is a worthwhile exercise, but now is not the time to perform this exercise.

Light Bulb On

I had to get several technology deals under my belt before I realised this, but at this early stage of the contracting process, you really need to focus first on terms and conditions that are important to you, not the terms and conditions that are important to your vendor. We know your vendor has included in its specimen contracts (as modified prior to presentation to you) all the terms and conditions of your deal that are important to your vendor. In fact, they are very easy to identify. They are all the contract terms with vendor bias. These provisions are so important to your vendor that it has purposely added bias to them, often with obvious exaggeration and redundancy. Even if your vendor has to bargain down somewhat from these provisions, your vendor is still in a safe position because the starting point was so extreme.

What You Should Do Instead

At this initial stage of contracting, you should ignore your vendor's proposed contracts. Simply set them aside for the time being, and do this for two reasons. First, in order to express in writing the terms and conditions that are most important to you, you must actually think of what those terms and conditions might be. Likeable as your vendor may be, your vendor will not have already added to its proposed contracts the terms and conditions most important to you for your particular project. You will have to come up with this stuff on your own.

Second, until you know what terms and conditions are most important to you for your particular project, you are in no position to challenge your vendor's biased provisions except in attempt to remove or limit the bias. "I don't know exactly what impact this provision has on our project, but I know it's not a provision that helps our cause." Challenging these provisions in a vacuum does not really help you.

The Big Picture

Now is the time to start with a fresh, big-picture perspective, and then fill in lots of detail. Circle back to earlier stages of your procurement process and revisit your decisions, your assumptions, and the various things you have learned. As a result of your many meetings and discussions, there may be things that you are now taking for granted: special vendor qualifications, how a particular piece of your project will be orchestrated, acutely risky aspects of your project, and so on. Bring to mind other similar projects within your organisation and apply what you learned from those experiences.

Re-acquainting yourself with prior thought processes, discoveries, assumptions, and experiences will help you remember aspects of your project that you previously deemed important, whether because they are critical to project success, they pose a substantial risk within your project, or perhaps both, and it will force you to consider the importance of other elements for the first time. This process will help you build out the terms and conditions for your deal that benefit and protect you, terms and conditions that maximise the probability of project success and minimise project risk.

As part of this process, make a detailed list of terms and conditions that are important for your particular project, and:

1. Categorise them by subject matter.

For example, requirements development and prioritisation, data mapping, business process issues, software development, application integration, database integration, system integration, testing, implementation, buyer protections, vendor management tools, warranties, etc. When you get around to negotiating the items on your list with your vendor, your project team will have important reference points. "Does this contract item touch implementation? If so, let's look at our implementation items."

2. Add qualifiers for each item.

Among other things, qualifiers can include a ranking of particular item's relative importance within your project (critical to project success, represents substantial risk, wish list, etc.). When you get around to negotiating the items on your list with your vendor, your project team will be less inclined to treat all items on your list as equally important. Almost certainly, not all will be equally important. Your team will have a sense of how hard to push on a particular item, and in terms of the give and take that occurs in any negotiation process, they will have sense of what items to compromise (and by how much) or concede outright if met by strong resistance from your vendor.

3. Add relevant notes and comments for each item.

Among other things, relevant notes to attach to your list items include comments about accountability. Who within your project will be accountable for accomplishing the particular item: your vendor, your internal staff, or some combination? And what should happen if the party with accountability drops the ball?

With this kind of list in hand, you are in a much better position to review your vendor's proposed contracts. Perhaps most important, you are no longer reviewing the contracts in a vacuum. You are equipped to conduct a truly meaningful review of your vendor's proposed contracts.

Is there a gap in the vendor's proposed contracts; that is, an item from your list has not been addressed at all? Is there an inaccuracy in the vendor's proposed contracts; that is, an item is addressed, but its present treatment does not match your understanding, preference or requirement? Are topics within the contracts miscategorised? Are interrelated items not treated as such? Are accountabilities not clearly established?

An Even Better Approach

Although breaking the mould and adopting the above approach to technology vendor contracting will certainly help you produce better contracts for your next technology project, which contracts should facilitate a better project outcome, there is a way to help yourself even further.

Instead of starting with and working from your vendors' proposed contracts for your next project, think about developing your own standard agreements to include within your technology procurement process (usually at the RFP stage). First, develop a neutral or somewhat buyer-favourable Software License Agreement. Find a standard Software License Agreement and neutralise or remove the elements of vendor bias. Then add the buyer-side content that you would normally find yourself negotiating with a typical vendor (were you working from the vendor's standard Software License Agreement). Next, find a standard Consulting Services Agreement and do the same thing.

You can add your newly-developed standard agreements to your next technology RFP and request that responding vendors either approve your standard agreements as-is, or cite alternative language for provisions they do not find acceptable.

By incorporating your standard agreements into your technology procurement process, you will achieve two important things. First, you will be able, probably for the first time, to evaluate vendor candidates based on one of the most important factors for project success, terms and conditions. You can guage a prospective vendors appetite for terms and conditions that are important to your for your particular project BEFORE you have selected a vendor. It is much harder to win favourable terms and conditions AFTER you have selected the vendor for your project. And second, you will greatly reduce negotiation cycle times.

More and more commercial information technology buyers, of all sizes, are using this approach. It may surprise you to learn that many reputable technology vendors will not only entertain the possibility of working from your standard agreements instead of theirs, they may even welcome the prospect because it saves them time and expense as well.

A Word of Caution

When you develop your own standard agreements, exercise some discipline. Do not convert a terribly vendor-biased agreement into a terribly buyer-biased agreement. This will not help your cause. Instead, shoot for balance. Software developers, for example, are entitled to and must protect their rights in their intellectual property, and there are certain limits beyond which they will not venture; for example, an excessively broad licence grant. Understand vendor limitations and be fair. Add buyer bias judiciously and only if it is truly important to your organisation.

The Purpose of Project Management and Setting Objectives

By Brian Miller

Project Management has developed in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects. All projects share one common characteristic - the projection of ideas and activities into new endeavours.

The purpose of project management is to foresee or predict as many dangers and problems as possible; and to plan, organise and control activities so that the project is completed as successfully as possible in spite of all the risks. The ever-present element of risk and uncertainty means that events and tasks leading to completion can never be foretold with absolute accuracy. For some complex or advanced projects, even the possibility of successful completion might be of serious doubt.

Project management can involve the following activities: planning - deciding what is to be done; organising - making arrangements; staffing - selecting the right people for the job; directing - giving instructions; monitoring - checking on progress; controlling - taking action to remedy hold ups; innovation - coming up with new solutions; representing - liaising with users.

Setting Objectives

Effective objectives in project management are specific. A specific objective increases the chances of leading to a specific outcome. Therefore objectives shouldn't be vague, such as "to improve customer relations," because they are not measurable. Objectives should show how successful a project has been, for example "to reduce customer complaints by 50%" would be a good objective. The measure can be, in some cases, a simple yes or no answer, for example, "did we reduce the number of customer complaints by 50%?"

While there may be one major project objective, in pursuing it there may be interim project objectives. In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired outcome. If they were to proceed in any other manner, they may not be able to develop the skills or insights along the way that will enable them to progress in a productive manner.

Objectives can often be set under three headings:

Performance and Quality

The end result of a project must fit the purpose for which it was intended. At one time, quality was seen as the responsibility of the quality control department. In more recent years the concept of total quality management has come to the fore, with the responsibility for quality shared by all staff from top management downwards.

Budget

The project must be completed without exceeding the authorised expenditure. Financial sources are not always inexhaustible and a project might be abandoned altogether if funds run out before completion. If that was to happen, the money and effort invested in the project would be forfeited and written off. In extreme cases the project contractor could face ruin. There are many projects where there is no direct profit motive, however it is still important to pay proper attention to the cost budgets, and financial management remains essential.

Time to Completion

Actual progress has to match or beat planned progress. All significant stages of the project must take place no later than their specified dates, to result in total completion on or before the planned finish date. The timescale objective is extremely important because late completion of a project is not very likely to please the project purchaser or the sponsor.

Conclusion

Project management has developed over the years, and involves various activities before a project is completed. Objectives should be specific so they are measureable, and although there may be one major project objective, there may be minor objectives throughout the project.

When Do I Turn on Project Management?

By Pierre Monacelli

The problem with project management and IT is that all too often, project management is an afterthought on a project. It is often perceived as "project control" or an administrative function that tracks issues and schedule dates based on best guesses. We are lured to "just get it done" and leap into development without adequate planning. With this approach, project management is seen as providing little or no value, which is understandable because it is inherently reactive when applied this way. Inevitably, projects will exceed prescribed time and budget parameters. To be effective, an organisation needs to invest in project management at the very beginning of the project life cycle. Yes, it does take time to plan and identify requirements, but the choice is to spend the time upfront at a much lower investment and with a smaller team, or spend a lot of time and money doing rework at the end at a much greater cost and with a much larger team.

Consider this scenario: The ABC Company has decided to implement an enterprise-wide technology that will improve and integrate all of its business applications and processes. After lengthy negotiations, the initiative is approved. ABC appoints a programme manager and the technology partners arrive to begin the implementation. The programme manager inherits a few key target dates, set by senior leadership during the previous negotiations. At first, the programme manager is optimistic. But as that programme manager begins to ask questions, it is evident that the devil is definitely in the details. As time goes on, cost and schedule overruns inevitably occur and consequently, performance expectations are dashed. So what went wrong? ABC had a programme management culture, augmented by a seasoned programme manager and a PMO. How could failure be possible given this ideal state of affairs?

And yet, project failure seems to happen all the time. Here are some of the driving behaviours that get us into these situations:

• The implementation of a new product or technology promises to address and resolve a lot of urgent business issues, so it needs to be up and running ASAP.
• Technical experts involved in upfront negotiations focus on the product and coding solution instead of taking a holistic programme management and business approach.
• Integrators make overly optimistic evaluations of how long integrations will take to complete and become accepted throughout the enterprise.
• Upfront planning is avoided or streamlined because it takes too much time.
• A "just get it done" mindset rules the day.

Using this type of "cart before the horse" approach would be the same as a construction crew arriving at the job site with all their equipment and resources, but no blueprints. These approaches undermine what programme management sets out to accomplish. An organisation facing any of these situations will have an uphill battle that will include the following symptoms:

• Re-engineering the upfront planning work that should have occurred.
• Resetting expectations with senior leadership.
• Rebuilding credibility with the user community.
• Managing the endless volume of change requests and rework.
• Explaining early indicators forecasting cost/schedule overruns.

These characteristics (as well as many others) all contribute to the cost/schedule overruns and burgeoning requirements.

So how can you mitigate these problems? The programme management function needs to be introduced and activated before negotiations to begin capturing key upfront information. Before a tool is unwrapped or even selected, your programme manager should know the answers to these questions:

• What business problems are we trying to address with this product/technology?
• What is our expected ROI?
• Who are our stakeholders?
• What are the stakeholder requirements?
• What is our existing business support architecture (processes and enabling technologies)?
• How will our existing business support architecture be impacted (reused, adjusted, augmented, removed)?
• What is our change management approach that will enable us to integrate the new technology into the organisation?

Not only will this information get the organisation off to a good start in terms of programme managing the effort and setting realistic expectations at all levels, it will also enable the organisation to:

• Make an informed make-or-buy decision.
• Help ensure the selection of the right products/technologies.
• Analyse alternatives and maximise re-use.
• Provide a baseline to ensure that the investment (once implemented) is paying off as expected.

After this information is collected and analysed, the programme management function can begin to translate it into the accepted and necessary planning tools (work breakdown structures, control accounts, master schedules, and other PM101 processes) that will support the control and analysis of the programme.

Because we do not live in an ideal world, sometimes organisations may not have the luxury of introducing the programme management function in the upfront activities mentioned here. Some challenges include changes in leadership, strategic direction, mission, priorities, and so on, which may have contributed to an organisation's inheritance of an ill-planned technology investment. If faced with that situation and clear symptoms of a poorly managed programme, the organisation will have to conduct an honest, unbiased assessment to ultimately support a "go/no-go" decision. This is a situation where an independent perspective is paramount. A no-go decision can be very difficult for an organisation, especially if a lot of time and resources have already been committed to the programme. That said, once the decision is made to terminate a programme, the programme management function will be focused on closeout processes and realigning resources. If the organisation decides to continue with the programme, it will have most likely have benefited from investing in a programme "time-out." The organisation can then refocus the programme management function to collect the critical upfront information before proceeding further.

Introducing programme management before an IT implementation can be a time-consuming activity. It takes a lot of hard work involving many stakeholders. But wouldn't your organisation prefer to have this information at hand before the technology is unwrapped and the meter starts running on the hours of effort your employees, vendors, and subcontractors put into costly rework? In either case, there is no free ride. But the upfront ride involving careful planning is ultimately cheaper, smoother and less painful than jolting ride involving brutal back-end rework and cost and schedule overruns.

Project Management Basics

By Michele Webb

If you have ever had responsibility for managing a project, regardless of how little or how big, you will understand the many nuances and special considerations that have to be taken into Post Optionsaccount behind-the-scenes. Project management success stories rarely show the struggles, problems or weaknesses of the project or team to the public. One author, Herbert Lovelace, likened this to the kitchen, which "...tends to be cleaned up before it is shown to guests!"

Understanding how projects should be managed or "by the book" methodology is a good reference guide and tool for everyone. But, in order to succeed the project manager must understand the myriad of people, their needs, and the potential problems and issues that need to be tackled before the project can be called successful. In my own experience, project management is a culmination of all the experiences and knowledge I have gained on past projects and is modified based on circumstance. There are, however, some very broad guidelines that can be implemented to help ensure the project stays on track.

1. Identification

Make sure the problem, or project purpose, is clearly identified before starting. This is best done by putting the purpose into writing and having the entire team review the text. Next, solicit the team's agreement to the purpose in a roundtable meeting. This will also help to identify the customer's concerns and issues that need to be addressed throughout the project and help to stratify the resources and potential conflicts the team may encounter.

2. Preparation

Is all about figuring out what to do and how to do it. Although most of us can handle the mechanics of preparation fairly well on an independent basis, it may be more difficult to ensure that all project team members are in agreement. It is advisable to have everyone sign off on what is to be done and his/her role in the project as part of the preparation. People are far more likely to support something that they understand and have had a role in developing. In our organisation we use a document, called a Scope of Work Agreement, as part of the contracts and negotiation process that details the work to be done on the project. By using this document we can clearly set the project tasks, milestones and timeline before the contracts are finalised. Here's one titbit, if you are trying to implement systems, and you can't explain it easily, don't implement it!

3. Implementation

Just remember, it is always tricky! Try to keep implementation as simple as possible and have a rollback strategy in place. How you react to unexpected issues will make the difference between success and failure. Don't demoralise a team working long hours by letting critical decisions hang or go unanswered. Make sure that everyone on the team is in the communication loop and has a stake in the project. By the same token, don't be afraid to use the rollback strategy if unexpected events sabotage the timeline.

4. Reflection

Is your most valuable tool. We all learn a lot after the project is over about what or how we might have done something differently. It is helpful to keep a written log during the project. The log can also be used as a tool after the project is over to figure out how things could have been improved. A post-project team meeting where all team members can contribute to the feedback is warranted and will produce valuable information from all stakeholders.

Conclusion

Project managers should take the time to learn from formal methodologies and utilise the help from mentors and other experienced project managers. In my humble estimation, though, there is no substitute for the "hands-on" approach to project management and planning. Regardless of the methodology or set of ideals you start out with, nothing will replace the amount of sweat, teamwork, hard work and personal involvement required to successful project management. You can reduce the number of problems and issues you deal with, however, by following these four simple guidelines.

Setting Measurable Project Objectives

By Dr. Keith Mathis

Examine ten projects at random, and you will see some of the worst written objectives. Project objectives are often hard to track, vague, and lacking in depth. In project objectives, people need details to help know where they are in the process, and data helps them make informed decisions. I like to recommend "DISCO" when forming objectives. "DISCO" can be spelled out to point us in the proper direction for creating project objectives and tracking their progress.

D - Detail Specifics

Give as much information as possible and make these objectives very specific. Far too many objectives have been set, which are very grey in nature and lack data to help team members understand all specifics.

I - Include Qualitative and Quantitative Measurements

Objectives must be measured. When you look at an objective, you must ask, "Can we measure this?" If not, it needs to be rewritten so that it can be measured and tracked for successful completion. The only way to do this is to make sure qualitative and quantitative components are set.

Qualitative measurements measure a project based on quality standards, quality indicators, or quality characteristics. Defect ratio, break down ratio, and improvement needs are all to be considered. Each of these can be prioritised and broken down into a specific tracking mechanism to follow and monitor.

Quantitative measurements measure the project based on numerical indicators. Some of the most common quantitative measurements are time, budget, production, work hours, process time, and development progress. Quantitative measurements normally include the need to set a series of benchmarks as a starting point to begin tracking.

S - Seek Consensus With the Team

Making sure the team agrees with the measurement is very important. Sometimes objectives are set at the beginning of the project, and they are very loose. When the team sets a standard of measurement, it will usually be detailed and understandable. It is important because the team needs to be on the same page during planning. They must agree that these standards are the best possible measurements considering the project.

C - Create a Reasonable Approach in Obtaining Those Objectives

The approach for reaching objectives is very important. Unless the approach is understood by the entire team and supported, there will be conflict in the team's processes. Conflict means you will have people going in different directions and using various methods.

O - Operate in a Methodical Timeframe

Setting up a timeline and follow it. This timeline must make sense and be publicised to the entire team. You must constantly focus on maintaining clarity.

An example of a great DISCO objective is, "We will design 15 training courses that meet organisational development guidelines by June 30 with a budget of $483,000. We will include courses on supervision, communication, performance appraisals, and creating an optimistic workplace." DISCO objectives can be very successful in pushing the project forward and bridging the gap for communication. However, good objectives will never write themselves, nor will they track themselves.

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.