Project Management

Technology Vendor Contracting: Breaking the Mould

2009-03-11T03:44:00.000-07:00

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

2009-03-09T03:46:00.000-07:00

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?

2009-03-07T03:48:00.000-08:00

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

2009-03-03T03:50:00.000-08:00

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

2009-03-01T03:53:00.000-08:00

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

2009-02-27T03:55:00.000-08:00

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

2009-02-25T03:57:00.000-08:00

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

2009-02-23T04:00:00.000-08:00

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 :

Add time - delay the project to give you more time to add the functionality
Add cost - recruit, hire or acquire more people to do the extra work
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

2009-02-21T04:00:00.000-08:00

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

2009-02-17T04:02:00.000-08:00

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.

Determine the objective and specific desired outcome. Write it down.
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.
Identify a project leader and co-ordinator, this should be accepted by all involved in the project. No consensus, keep trying.
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.
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.
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.
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.
Organise the tasks and sub-tasks in chronological order. Write it down.
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.
Develop a list of initial actions and outcomes that must be started and completed. Identify the responsible parties and dates. Write it down.
Request specific (realistic) dates for the completion of tasks, sub-tasks and objectives. Write it down.
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.
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.
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.
For any major problems or setbacks, get the group together to work out new scenarios and dates of completion.
Celebrate the big milestones and victories.

How to Keep a Design Project Moving

2009-02-15T04:16:00.000-08:00

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

2009-02-13T04:17:00.000-08:00

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.

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.
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.
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.
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

2009-02-11T04:19:00.000-08:00

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

2009-02-09T04:20:00.000-08:00

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:

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.
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

2009-02-07T04:21:00.000-08:00

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

2009-02-05T04:21:00.000-08:00

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

2009-02-03T04:23:00.000-08:00

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:

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
Practice exception reporting
Communicate on a regular basis with your sponsor and other key stakeholders
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

2009-02-01T03:55:00.000-08:00

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

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!"
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.
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.
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.
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.

Strategies for Managing Change: The Project Manager

2008-12-31T04:24:00.000-08:00

By Tom O'Dea

Some will disagree, but I don't care if your project manager is PMI certified or not. You need to care about having a project manager with the skill to carry out the role as the Institute defines it. It's your change management strategy, and it's your reputation on the line.

Finding a Project Manager

Do you need a certified Project Management Professional (PMP)? As I said above, I don't care. There are newly certified PMP's who have taken their tests and gotten the certification, but they may not be battle tested. There are veteran project managers who never got the fancy title, but they know how to manage projects. And there is everything in between. The track record is what you need to care about.

Do you have a strong PM on your team now? Is that person well respected, perhaps a key opinion leader in your organisation? Do they treat project management as a profession? Then by all means use them.

If, on the other hand, project manager has been a title used by junior, untrained people who walk around with a task list and a clipboard, it's time to bring on stronger talent.

Your fastest route to a proven project manager will be a contract hire, either from a reputable firm or an independent. There are many good ones out there. Get and check references, and interview at least three. Let your key opinion leaders and managers interview them as well. Look for their track record and for good chemistry.

Set the Project Manager Up for Success

Simply put, everyone needs to understand that the project manager is your alter ego. Everyone includes you.

Your managers and project leaders must understand that they are accountable to the PM for providing all of their tasks, their dependencies on other tasks and other work units, their schedule commitments, and their resource requirements.

They need to understand that the PM will review all of their information and look for problems. These could include missed tasks, schedule inconsistencies, resource overloads, etc. Often managers will tell the PM that they can handle some of these problems, by working people longer hours or by overlapping some tasks "by a day or two." A good project manager is going to challenge such claims, and you'll need to stand behind the PM.

The PM is going to hold everyone accountable for milestone deliverables. In most projects, especially those that are complex, milestones are missed and contingency plans must be activated. Again, you as the leader need to support the PM as they hold people accountable.

Handling Conflicts

It's entirely possible that the PM will have conflicts with managers, team leads or others in the organisation. Make it safe for people to discuss and bring up such conflicts. Just because the PM is your alter ego doesn't make them right, any more than you are always right.

Engage your key opinion leaders along with the project manager and others. Find out the facts contributing to the conflict, and make the decisions necessary to get the change management strategy back on track.

Change management strategies that fail often do so because of poor project management. Don't let that happen to you.

Understanding Change in a Quality Culture

2008-12-29T04:27:00.000-08:00

By John W. Wright III

In any improvement process, managing the influence of change and the anti-change culture that will continually try to raise its head will be one of the most ardent tasks. Learn to deal with this as effectively as you do the project management itself. There are many well-written books on the subject of change in every category of change that you could imagine. Below is a compiled list of items about change that are relevant to implementing process change.

When examining change it is necessary to understand the stages of change that have been identified. It is interesting to note that these stages take place in varying degrees in different people, but are exactly the same whether the change is a different process in the workplace or the death of someone close. You should be able to identify and deal with the levels of acceptance encountered. Here are the stages and some tips on how to deal with them.

Denial

A wonderful self-preservation response. It is characterised by minimising the situation, and saying (or thinking) things like "This isn't happening", "It won't help", and "There's no problem." You may find the person will avoid talking about the situation, or even make up excuses for not attending meetings.

Explain the denial to commitment process that you went through to get where you are.
Present the situation openly and allow a lot of time for questions and answers.
Have a training session on change management.
Present a caring and understanding front. Though this may not be your normal attitude, during this process it will be invaluable.
Be a broken record with memos, thank you emails, posters, or anything else that presents your platform in a positive light.

Resistance

It is at this stage that you may see the active signs of sabotage. They may be passive, as in "I'll just do it my way anyway", along with a lot of whining-crabbing about the new systems. Or they may manifest in physical methods of sabotage depending on the character of the person. Be aware that these are real threats to the success of any project. But for the most part, those who fall into this category will show a lack of interest and a lot of time spent on finding reasons it won't work.

Listen! And I mean listen. You can hear more in the tone and inflection of what is being said as well as the body language than you can imagine.
Solicit Response. People love to know that they are being heard and even more that their suggestions are valid. Many of them are. These are the people who will make or break the installation, let them know they have input to the outcome.
Acknowledge Feelings. Let them know you went through a similar process in getting where you are. Validate that they are not alone.

Exploration

People will begin to see some of the good that may occur in the situation, and will generally vacillate between thinking that it might be ok and that it is still a bad idea. But, the up side is that you are beginning to get them on your side and they will begin to make effort to get the changes in place.

Facilitate. People are more open at this point. Take advantage of it. Be your own commercial! Challenge people to find a better way within the new system. It gets them thinking about the next round of change and off the current.
Reward forward thinking with mounds of compliments. Praise the desired behaviour.
Seek out new possibilities. Have brainstorming sessions. It does wonders for everyone's moral.

Commitment

You've got buy-in and will see productivity through the changes. People can see the bigger picture and the opportunity that the change affords.

When dealing with this from a management point of view, it is important to remember several things. These feelings are very real and they happen at different times for different areas of the organisation. Do not expect to spend several months agonising over the commitment to purchase expensive software only to turn around and expect everyone else to do a Tarzan swing from denial to commitment in a week. Remember the process you had to get through in order to accept the change. Others will require the same; allow the process to manifest itself in others. You can facilitate the process by understanding it and helping others to get through.

Recognise and acknowledge those who get there. Give them more opportunity to improve the process and celebrate their victories.
Inspire people to get others on board. Teach them about the process and how to recognise the people in various stages and how to move them along.
CELEBRATE!!!!! Most important. When you have achieved goals, let everyone know and celebrate, celebrate, celebrate. When people know their efforts will be recognised and appreciated, you will have fewer problems in future change.

Remember that we have a tremendous amount of information to process every day. There is more information in a single daily paper today than a person in the 15th century processed in a lifetime. Change takes form in one of three types; that which we cannot control, that which we can, and that which we can influence. Being positive and trying to move things from cannot control to can influence helps in the ability to manage the changes that occur. But, there will always be those things you cannot control and acceptance of that fact is the only road to remaining sane.

Managing Change Successfully: Six Layers of Resistance

2008-12-27T04:28:00.000-08:00

By Samuel Okoro

Why is there resistance to change? Are people just naturally perverse, or are there concerns which if understood and correctly dealt with will create the buy-in required to turn resisters into supporters and generate the momentum needed to overcome the gravitational pull of the status quo?

There are six layers at which resistance can occur.

We Do Not Agree on the Problem

Go into any poorly performing organisation and ask people from various functions what the issues are. In all likelihood, within each function you will find different opinions as to what the problem is. The situation is not unlike the six blind men in the rhyme, who went to see the elephant. Each honestly describes his experience, but none of them captures the essence of the whole.

This is why different initiatives are launched in each department to try and solve the different problems. But if we remember that organisation are systems and departments/functions are interacting parts of a whole, we then realise a more holistic approach is needed. Through a combination of rigorous logic and experience based intuition, we build tight cause effect relationships that lead us to the core problem.

Usually disagreements as to the problem disappear once this approach is used.

We Do Not Agree on the Direction of the Solution

If a problem is long standing, its persistence indicates that there are conflicts preventing its successful resolution. An example of such a conflict is where management proclaims quality as number one and generally supports actions that guarantee quality until sales volumes are threatened. Then the quality mantra is quickly abandoned - especially if we are talking about the last quarter of the year. When the pressure eases early in the new year, quality becomes important again.

Another case is the conflict between delegation - to improve speed of operations and customer service on one hand, and control - to contain costs on the other hand.

By questioning the assumptions behind each of the conflicting positions, erroneous paradigms can be unearthed and thus the basis of the conflict eliminated. Thus a particular direction for solving agreed problems can be pursued. A powerful tool for resolving conflicts is the Evaporating Cloud which is part of the TOC logical tool set.

We Do Not Agree that the Proposed Solution Resolves the Problem

Even with the problem and the general direction of the solution agreed, it may be difficult to convince stakeholders that a particular solution completely solves the problem. In this case just as logical cause effect relationships can be used to construct a diagram to represent the problem so also can they be used to construct a diagram logically relating the proposed solution to the new desired states.

Thus such a logical description can be used to convince stakeholders that all the original problems are eliminated when the solution is implemented.

Yes But... the Proposed Solution Will Create Other Problems

It is not unusual that the designer of the solution is blind to the shortcomings. So even though stakeholders now agree that the solution solves the stated problem, they may claim that it creates other problems in their place, like the case where eliminating a pest causes a proliferation of other undesirable creatures that it preyed upon.

The solution here is to acknowledge the concern and then work with those affected to eliminate it by the same logical process already described. Involvement of affected stakeholders creates even stronger buy-in. At this point every one is ready and willing to go ahead, but...

Yes But... there are Huge Obstacles to Implementing the Proposed Solution

The solutions proposed may require skills, resources, technologies, approvals that are currently unavailable. The obstacles are attacked in a step by step manner. The outcome of the process is a sequence of prerequisites needed to overcome the obstacle and thus implement the solution. At this point there is complete buy-in along with a plan for executing the required changes.

Unverbalised Fear

At the end of the day, any residual resistance is most likely due to unverbalised fear - a vague feeling of unease arising from the fact that we will be doing something entirely new. Leadership is what is needed here to provide the inspiration and confidence to go forth and just do it!

Making Change Happen

2008-12-25T04:30:00.000-08:00

By Kevin Dwyer

Seventy percent of all change management projects are considered to be failures.

The critical factors for change management success or failure are fairly simple.

The first factor is to have a group of people at leadership level believe that change is required. More than that, they must believe that "change management" is required. If these factors are not evident then failure is assured.

Understanding that major change is required is not enough. Developing a project plan which includes changes to processes, policies and infrastructure that does not include a plan to manage the change at a people level is not enough.

The second requirement is that the people undergoing change must have a reason to believe the change is necessary. They need the big picture painted for them to understand what benefits the organisation will gain from what many people will consider as the shared pain of change.

The big picture must be compelling, giving as many people in the organisation the desire to embrace the change even if it is difficult. Organisational change for organisational change's sake is likely to fail to deliver change.

The third requirement is that individuals must know how the change will affect them as individuals. Never forget the greatest motivational tool is to be able to respond to the question, "What's in it for me?"

For most individuals in most organisations, motivation is about achievement, recognition, the work itself, responsibility, advancement and personal growth. So be sure that the change message addresses as best it can the motivational opportunities for people.

The fourth requirement is to "tell them early, tell them often." Do not be surprised how many times the message needs to be repeated to the same people. Human beings filter information based on their emotional state, their previous experiences and their thinking styles. In a time of significant change people are often in emotional turmoil and will filter severely whatever they are told.

Tell people the compelling reason for the change, the plan for change, the progress of the plan for change including any early wins and their role in change, again and again as the project is implemented.

The fifth requirement is to be honest about the change. Sugar coating change is seen as being untrustworthy and will adversely impact the ability to communicate with the very people who have to embrace and implement the change.

If there is any bad news say so. If jobs are going to be lost, say so. If there are going to be challenges with the change, say so. If people have to re-skill, say so. If the targets are going to become much tougher, say so. Do not dress mutton as lamb. If an insignificant advantage will accrue to people, do not make it seem more significant than it is.

If you are honest about change and you don't know about some of the implications, you may have a significant number of people actually believe you. When you ask for help in making the change work, you may get a positive response. Be dishonest and even your best workers will smell a rat and treat you like one.

The sixth requirement is to utilise project management processes and skills. For those involved in change management who do not use project management processes and skills the simple advice is, "If I were you, I would not have started there."

Project management processes and outputs play a big part in both planning and communicating the changes anticipated. They assist in risk management, contingency planning, change control, resource management, prioritisation and post implementation review of the change.

Far too many organisations embark on change in manner best described in the vernacular language, as flying by the seat of their pants. They do not plan change. They do not estimate the resources required by change. They do not plan the precursors to events required to make the change happen. They do not understand the risks and plan the contingencies. They usually reap the rewards with a failed change project.

Managing change is not easy. However, it is not as difficult as a seventy percent failure rate would make it seem. It needs to be taken as seriously as managing the finances of an organisation or the safety of an organisation.

Managing change requires a leadership team with project management, communication and analytical skills with a high degree of results orientation. The latter is important as when a journey of change is embarked upon, the environment in which the change is being implemented immediately changes. A changing environment often calls for changed tactics to achieve the same result.

More than that it requires the leadership team to have a vision for what the change can bring to the organisation and to individuals and a passion to make that change happen.

Push-Me Pull-You Projects

2008-12-23T04:32:00.000-08:00

By James Barlow

You have a concept, a plan and a team, and now you're about to start your project. But hold on a second: are your objectives coherent, or are you trying to change an organisation in two completely different ways. Are you about to start a Push-Me Pull-You Project?

Let's think about why we try to change things. At a high level, we can identify three dimensions of change, each concentrating on improving a different aspect of an organisation:

Capacity: Projects whose goal is to increase productivity; for example, by conducting more transactions or achieving greater sales volume using existing staff and resources.
Cost: Projects whose goal is to increase efficiency, identify savings and reduce unnecessary spend.
Conservation: Projects whose goal is to maintain the status quo, protect the organisation from exceptional events and respond to a change in the surrounding environment.

These theoretical types provide us with a quick guide as to the coherence of a planned project. In practice the scope of works may wander across these hard boundaries but unless the overall objective can be largely contained in one dimension, then the project executive and team are setting themselves up for future headaches.

Consider a project that is designed to achieve an equal mixture of capacity/cost objectives. The team will be trying to achieve more with the same resources - increasing productivity - at the same time as trying to achieve the same with fewer resources - increasing efficiency. These two objectives are mutually exclusive, and we have a textbook example of a Push-Me Pull-You Project.

How can we measure improvements in productivity if we are also cutting resource levels. Equally, how can we improve efficiency if an organisation is in the midst of changes to their processes and other ways of working in pursuit of productivity?

To resolve this situation pragmatically, we must accept that the project exists to serve the host organisation, so there is little to be gained from refusing the scope of works. But we can structure that work in such a way that we are not trying to push and pull at the same time. The optimum approach is cyclical, where the project implements change in one dimension, validates that change against the original scope and then allows a period of stability before undertaking change in a different dimension.

Alternatively, one can partition an organisation in such a way that different dimensions of change can occur simultaneously - for example in different departments or business units. This approach is attractive in that potentially one can identify a "control group" to be used in an objective comparison of the post-project organisation against original conditions. Evidence-based management of this kind is often difficult to perform in the real world, so the opportunity may be valuable to your project. But take care - weak partitioning will do nothing to ameliorate the risks of multi-dimensional change.

What about other multi-dimensional projects? A capacity/conservation or cost/conservation mix are both at risk from the same failure mode - a tendency to overspend on conservation measures which are by definition a step removed from the core economy of an organisation.

Conservation projects are intrinsically the most difficult to deliver well, since the natural human response to uncertainty is excessive expenditure on the amelioration of unquantifiable but high-visibility risk, even where such expenditure is difficult to justify on purely economic grounds. The key problem is that the benefits associated with conservation projects are bounded above and yet there is no intrinsic upper boundary on the potential expenditure that can be used to achieve them.

The unpleasant possibility of unbounded expenditure does not sit well with productivity or efficiency oriented goals, and there is much less opportunity for goal partitioning. Therefore conservation goals are best scheduled to avoid coinciding with other dimensions of change.

Overall, the message that needs to be internalised by both project owners and projects teams is that, when faced with a complex scope of work, look beyond technical or organisational criteria for structuring the project. The use of stages, as recommended by industry standards such as PMI or PRINCE2, is valid but look beyond the obvious to the fundamental dimensions of change. Consider whether you are trying to simultaneously push and pull an organisation, and look for ways to separate these goals. Don't waste your energy and the goodwill of your customers on Push-Me Pull-You Projects.

What is Change Management?

2008-12-21T04:54:00.000-08:00

By Duncan Haughey, PMP

The change management process is key to the successful outcome of a project. The process ensures that each change introduced is properly defined, considered and approved before implementation. Change management contains four stages:

Proposing a change
Summary of impact
Decision
Implementing a change

Proposing a Change

This process give the ability to anyone within the team (including the customer) to propose a change to a project. The proposal must include a description of the change and expected benefits or other reason for the change and is presented using a Change Request Form.

Summary of Impact

This process is carried out by the project manager who will log the change and consider the overall impact on the project. The following will be considered:

Quantifiable cost savings and/or benefits
Estimated cost
Impact on timescales
Additional resources required
Impact on other projects and activities
Additional risk and issues

Following this assessment, the project manager will make a recommendation whether to implement the change.

Decision

This process involves a review of the change request by an approved authority who will consider all of the information provided by the person making the request and the project manager. The decision will usually be to accept, accept with comments and/or special conditions or reject.

Change Management in Practice: Why Does Change Fail?

2008-12-21T04:53:00.000-08:00

By Jonathan Palmer

Resistance to change may be active or passive, overt or covert, individual or organised, aggressive or timid and on occasions totally justified.

Sadly most significant change fails to meet the expectations and targets of the proposers. The failure is given the catchall name resistance, yet resistance can be principled and creative as well as from vested interest. Top management is frequently unreasonable in its expectations and time scale, forgetting the process it went through when it decided to make the change.

An effective change manager will prepare an organisation for change in the early stages of project definition and stakeholder review, by taking managers through a similar sales process and responding to their apparent resistance: the creative conflict.

This process is likely to improve the project definition and buy in. It will also ensure that it is clear the moment resistance becomes vested interest.

It is unrealistic to expect an independent change manager to tackle vested interest resistance but the change director can use his or her intervention as a signal to the organisation - such interventions should be few but telling.

An independent change manager is a cross between a foil and a lightning conductor - the foil ensuring that positive energy is deflected to the right place, the lightening conductor removing negative energy from the organisation.

Avoiding failure: managing resistance

Resistance is a key element in why change fails. A recent informal UK survey of 120 government transformation programmes identified that:

15% achieved their objectives
A further 20% failed to achieve their objectives but were nevertheless regarded as satisfactory
65% were unsatisfactory.

A subsequent discussion forum on ecademy.com identified 7 key reasons why change fails. (The list is virtually identical to one made by Kotter at Harvard 15 years ago).

The organisation had not been clear about the reasons for the change and the overall objectives. This plays into the hands of any vested interests.
They had failed to move from talking to action quickly enough. This leads to mixed messages and gives resistance a better opportunity to focus.
The leaders had not been prepared for the change of management style required to manage a changed business or one where change is the norm. "Change programmes" fail in that they are seen as just that: "programmers". The mentality of "now we're going to do change and then we'll get back to normal" causes the failure. Change as the cliche goes is a constant; so a one off programme, which presumably has a start and a finish, doesn't address the long-term change in management style.
They had chosen a change methodology or approach that did not suit the business. Or worse still had piled methodology upon methodology, programme upon programme. One organisation had 6 sigma, balanced scorecard and IIP methodology all at the same time.
The organisation had not been prepared and the internal culture had 'pushed back' against the change.
The business had 'ram raided' certain functions with little regard to the overall business (i.e. they had changed one part of the process and not considered the impact up or downstream) In short they had panicked and were looking for a quick win or to declare victory too soon.
They had set the strategic direction for the change and then the leaders had remained remote from the change (sometimes called 'Distance Transformation') leaving the actual change to less motivated people. Success has many parents; failure is an orphan.

Very few organisations will manage all 7! However any one in isolation will make the change programme inconsistent and aggravate resistance. Advance planning and stakeholder management will avoid some of these pitfalls. Furthermore the list is an invaluable diagnostic tool for identifying why (and where) resistance is taking place, giving an opportunity to defuse resistance by correcting the mistake.

Conclusion

Resistance can be healthy (a pearl can result)
Unknown, unanticipated, unquantified, unaddressed resistance will always be dangerous.
A badly thought out process and implementation will always result in resistance
An independent change manager can bring the independence, experience, and objectivity to manage resistance.
A successful change is essential in creating a change culture

Persuasion and Perception

2008-12-19T04:55:00.000-08:00

By James Barlow

Every year, between forty and seventy percent of all corporations and public sector bodies attempt to make strategic change. Overwhelmingly, formal projects are the preferred structure used to organise such effort, regardless of whether the underlying goals are defined in terms of business process reengineering (BPR), technology upgrades, mergers and acquisitions, due diligence or similar concepts.

Each organisation starts with a desire to make itself better. But "better" is a slippery concept. Certainly projects bring about change, but do they necessarily make things better? Better in the board room might mean lower costs through reduced head count, but would the rest of the team agree? Perspective matters.

In the absence of personal control of events, everybody hates change. A failure to remember this fundamental insight is the root cause of a great many failed projects. Sophisticated communication strategies and planning models may impress project owners, but these tools will not persuade a hostile group of users or stakeholders that a new project will improve their lot in life; certainly not when their instincts and reflexes are telling them to resist.

This resistance may manifest as scepticism of the projects aims or an unwillingness to contribute, but the diametric opposite is also common - those affected may leap in with enthusiasm to suggest, amend and discuss all aspects of the proposed change. While this may seem productive, and there may be no conscious efforts at sabotage, the underlying desire is to minimise the threat of the unknown; to control it, and thus to make it familiar.

Multiply this process by the number of people affected by a project and the net result is a myriad of different requests, memos, change notes, delays, clarifications, amendments to minutes, design reviews, audits, strategy seminars, away days, planning meetings and other artefacts of partial control. A further difficulty arises since stakeholders are not necessarily customers. The difference is simple, if money changes hands, it's a supplier-customer relationship; everyone else is a stakeholder. Stakeholders may be in a position to influence requirements and outcomes, but they don't have a direct financial interest in the project. And there's no money as easily wasted as other people's money.

Paradoxically then, although many project managers are criticised for failing to engage with their customers, there is just as much trouble to be found by too much engagement. A tricky situation...

What strategies are available to counter these problems, then? Very few project managers have the authority to forego persuasion on those affected by projects, and compel the wider organisation, and yet persuasion is not enough. There are also plenty of problems with a more autocratic style of leadership.

As project managers, we need a way to provide those on the receiving end of a project with a degree of control, without sacrificing the momentum of the project. And this is not as difficult as it might sound, as long as the project is properly structured and - of course - as long as you stay pragmatic. There are two simple, core methods.

The first method is to consider how to minimise the psychological impact of change. The single most effective technique for achieving this is to introduce a number of small, symbolic, changes early in the project and use these as a mechanism to create a perception of ownership, and thus the perception of personal control.

I say "perception of personal control," but a more cynical observer might call it the "illusion of personal control." They are not synonymous, though, since the underlying purpose of guiding perception is not to manipulate, but rather to encourage project stakeholders to focus on the benefits they will gain from a project; not the short term problems they will face on the path to improvement. This technique gels well with other pragmatic project management techniques- early prototyping, user evaluation and feedback. The only caveat is that such user involvement is structured and leads to a positive outcome.

The alternative is to present the stakeholders of a project with so much change that they are faced with an unpalatable challenge to their existing ways of working. This could be considered as offering total liberty to those most affected by the project. But in fact, it can be demonstrated that the outcome is to overwhelm them with choice. Remember, in the absence of personal control, everybody hates change.

The second method is to manage expectations, by controlling the release of change. Release management is a familiar discipline to anyone working in software engineering, and the related field of configuration management is an integral part of the physical engineering disciplines. The same methods - even the same processes - can be applied to change - specifically to the presentation and handover of project deliverables.

A crucial point in expectations management is to limit the magnitude of your promises. By their nature projects involve risk and uncertainty. After all, if you were doing something routine and predictable, why go to all the effort of creating a project? So accept that things will go wrong, and that consequently until you have objective evidence that your supply chain and team can perform, you are not helping the stakeholders by offering a fantasy instead of cold, unpleasant reality.

Try these techniques the next time you want to you want to make a change to your organisation. But always ask yourself, "Is this a change for the better, or change for change's sake?"

7 Steps to Project Success

2008-12-17T04:14:00.000-08:00

By Peter Draper

The successful completion of a big project should bring big benefits for your company - otherwise, why bother? The prize sought is often increased customer satisfaction, bigger profits, higher share price or some other key performance indicator. Projects often require company staff, experts and suppliers to come together on a temporary basis to carry out a one-off change that will leapfrog the company to greater success. But all too often, the hope of success meets with problems, delays and cost over-runs that cause frustration and stress for everyone concerned. The project that looked so good on the drawing board may somehow fail despite all seemingly reasonable efforts. So, what might be done to improve your project's chances of success?

Here is a seven step procedure that I use to manage successful projects. It guarantees the best chance of achieving maximum project benefits for my clients. This checklist should also be useful to senior company executives, functional chiefs and project managers alike. My procedural checklist keeps profits in mind as follows:

Profit from your project
Rally support
Organise plans, resources, etc
Focus on key benefits
Invoke risk responses in advance
Test your project is working
Switch to the new working practices

Step 1: Profit From Your Project

Think about it. Every part of every organisation needs to generate more benefit than it consumes. So, if your project, even on the drawing board, cannot produce profits for the company, then no amount of management effort further down the line is going to be help. I have seen many examples of proposed projects that have benefit to cost ratios that only barely meet the company investment hurdle rates. These benefits are also sometimes "inflated" using some proposed value of intangible items. If this is the case with your project, then maybe it is time to look deeper and consider other alternatives before you start. As the responsible executive, before you kick-off your project, I suggest you make sure that you have some good answers to the following questions:

What is your company's business strategy?
How will the outcome of this project add value to that strategy?
What alternatives are there to doing this project?
What dollar-value is this project outcome? (Get your finance staff to calculate internal rate of return, etc.)
Is your project, in fact, mainly designed to avert some impending crisis?
What contingency needs to be developed in the unlikely event that your project outcome may benefit from some additional support?

By considering the answers to these questions you should have most of the information required to justify the need, and hence, determine the expected benefits for your project. Select your project carefully.

Step 2: Rally Support

In addition to getting the top-level support from your executive management team, it is critical to rally support and get input from other interested parties too. For example, major customers may need to be consulted, as may representatives of the planned user base too.

These parties interested in the outcome of your project will:

Contribute to your list of the benefits and also dis-benefits of the project
Possess a wealth of expertise and experience for you to consult and gain valuable advice from
Be the main candidates for providing funding or support for your project

The purpose of this step is to develop a clear picture of how your project will come together in more detail. The step is highly consultative and requires answers to the following questions:

Has a similar project to this ever been done before? If so can this be used as a model?
How could your project outcome be improved for the various interested parties?
What legitimate concerns do the other interested parties have regarding your project?
Are all parties in agreement with all the assumptions made?
Should the order of magnitude costs and expected benefits be modified?
What dependencies are there relating to other current projects?

Once these questions have been addressed you must check that the executive management team, major customers and other key parties are all on-board. They need to be aligned as much as possible to enable the required degree of collective ownership. Now you should have a great start to your project and a high degree of confidence that you will get those sought after benefits.

Step 3: Organise Plans, Resources, etc.

A key appointment on your project team is the project manager. He will take full and personal responsibility for achieving the successful outcome of your project using the best methods available. He organises everything. His starting point to getting the best resources, to negotiating the best contracts, to managing your project is to communicate effectively with all the relevant parties concerned. The key is to be communicating "facts" such as requirements and plans. He should be aware that communication is a two-way street and much of the time should be spent getting feedback and seeking information from knowledgeable parties.

The project manager is also an integrator. In particular, he integrates the project team and other interested parties, and he also integrates products and services. Any new product or service resulting from a project will need to be merged with the company infrastructure on "live" date. In building the project plan it is essential to break the work down into manageable units. However, in every area from technology to manufacturing to human resources there is currently an opportunity to leverage off standard models and structures. So ensure the project manager uses industry standards where possible, for example using:

Process models (such as the Project Management Institute's project management methodology)
Architecture models to enable "pick 'n' mix" type deliverables

It makes sense to consider outsourcing project activities and deliverables unless, say, for security reasons it must be in-house or perhaps it is somehow part of your core business.

Step 4: Focus on Key Benefits

Once the project has been planned, it is important to stay focused on key benefits. The problem is that projects tend to take on lives of their own. You cannot let this happen otherwise all sorts of side tracks may be taken or other features added in. It will probably be necessary to break up the project into smaller, independent sub-projects that are more easily manageable. These sub-projects must be:

Small, that is, less than $1m
Fast, that is, takes less than 6 months
Compact, that is, fewer than 6 people on the team
Focused on key benefits and not just deliverables

This is also the time to reconsider carefully again the desired project objective. Do these sub-projects really produce tangible added value in dollar amounts? It may be that considering the additional costs, many of these lesser features may be dropped to achieve project efficiency gains. Remember, jettison non-essentials and focus your project to do ONLY the items that MUST be done to achieve the benefits you really need.

Step 5: Invoke Risk Responses in Advance

During the life of your project the world is not standing still. Competitors are introducing changes, customers' demands are changing, technology is moving forward at near breakneck speed, etc. You cannot keep up with all this on your own. You must empower your project team to anticipate problems and you must tell them how you want them to deal with these issues in advance. Some studies show that up to 90% of project problems can be handled effectively by using proactive risk management similar to that described below. Here are the questions to ask:

What problems have been encountered on similar projects in the past?
What else can possibly go wrong at each stage of this project?
What are the early warning signs of these problems occurring?
What is the dollar impact of each possible problem that has been identified?
What is the likelihood each problem might occur?
What response strategy is best to handle each of these possible problems?

Evading the problem altogether is a good strategy for coping with risks, but alternatively, you might want to use one of the following standard risk responses:

Avoidance - eliminating the cause
Mitigation - reducing the effect
Acceptance - simply accepting the impact
Transference - "outsourcing" the problem

Managing project risks means anticipating them to avoid "fire-fighting" responses; and replacing them with prior delegated actions. This way your project outcome and benefits can be protected to a very large degree.

Step 6: Test Your Project is Working

Controlling your project involves testing and checking progress, then making adjustments to bring your project back on course. This means deciding up front what key measurements need to be taken and how often; and then deciding what values for these items make them unacceptable. Examples of such measures are:

Work done (pay special attention to "scope creep")
Cost variances
Activities behind schedule
Quality issues

These need to be considered on a "management by exception" basis and the facts need to be reported to interested parties. At the same time adjustments can be made to activities to bring these factors back into line immediately. This way, you can guide your project to a successful outcome. But be careful that watching paperwork alone is not enough. There will be critical times on any project when you must know how to motivate your team to achieve exceptional results.

Step 7: Switch to the New Working Practices

Congratulations! You have reached the final step. You now have to make sure you complete the last step to get those hard earned benefits. This generally requires switching off that out-going system, or re-deploying the department you have just made unnecessary, or simply stopping using that old set of procedures. To get the full project benefits, you need to switch to the new working practices completely. This final act often requires courage and resolve. I have come across many examples, say, of an old system that is never switched off because it is needed for that "special" client, or whole departments that continue in parallel years after a major company merger.

Of course, you should finally celebrate a job well done!

Real World Project Management: Procurement Management

2008-12-17T03:59:00.001-08:00

By Joseph Phillips

Projects typically need stuff: servers, software, subject matter experts, pizza, etc. And to buy all this stuff, you need to go through procurement processes. That's just a fancy way of saying you need to follow some rules and procedures within your organisation to get the things you need to complete your project. Well, duh.

In some organisations where I've consulted, the project managers can spend carte blanche up to $10,000 on any purchases they need. In other, less fun organisations, the project managers can't buy a soda pop without an accountant's permission.

So where are you? Do you get to buy, buy, buy, or is every purchase considered, weighed, and meditated on before someone reaches for the wallet? In either shop, there are some guidelines you should consider. Really, there are.

Planning What to Buy

All purchases require some level of planning. The intensity of the planning is relevant to the purchase being made. You do this already, right? If you're about to install a new piece of hardware, you'll consider all the functions that the hardware should have, shop around a bit for prices, and then see how much your project or organisation can spend (or is willing to spend).

Planning for procurement includes more than window shopping. Think way, way back to the start of any project that required procurement. Early in the project planning, it was easy to identify those things or services that you needed to buy for the project to succeed. As the project moved forward, "emergencies" popped up, requiring you to buy more stuff: cables, software, additional hardware, tools, training, spaghetti sauce, whatever. So how did you go about getting all this stuff? Did you go to management, hat in hand, and plead your case for your much-needed spaghetti sauce, or did you dip into a project contingency fund?

How you go about purchasing depends on the structure within your organisation. It's difficult, if not impossible, to define a universal approach to procurement. Everybody, every organisation, has a specific approach to procurement. The moral of the story? Follow the rules. Once you know the rules of how to procure, then you can play the game.

Gettin' to the Gettin'

I know lots of people who like to go shopping. One person (who shall remain nameless, but her initials are Lisa) plans her vacations based on the shopping malls in the vicinity of her hotel. She buys an extra seat for the flight home, just to carry all of her new shoes and fancy outfits.

As a project manager, you can't go project shopping just because shoes are on sale. While sales are good, they don't always help the project to acquire the things it needs to reach project closure.

There's nothing better than finding a sale on the hardware or software that your project needs, but you and I know that's just not the way technology and procurement usually works. We have to shop, compare, evaluate, and eventually cough up the cash to get what our projects need. But here's some Econ 101 for you: Prices are affected by supply and demand, pending changes, and other factors, from government regulations to the economy as a whole.

I can hear you again: Duh.

But hold that "duh" for one moment. Three specific conditions affect how much you pay for the things your project needs:

Sole source. In this condition, you'll likely pay big bucks. Sole source means there is only one qualified seller in the market. This is supply and demand at its finest. If your project needs a Cisco CCIE-certified consultant who must also know how to program in COBOL, speak Spanish, and cook spaghetti for up to forty people, and must live local to your firm, those are some high requirements, you'll likely have to pay a higher dollar for this expert than for your average spaghetti-cooking hack.
Single source. You're in love. When there's a single source provider, your organisation prefers to work with this provider even though other providers may be less costly or more qualified. The danger is that your single source provider may know your attachment and take advantage of the situation. Or get lax in their commitment to quality. Or go out of business. (Or not.)
Oligopoly. This one is just fun to say. Try it: Oh-lig-AH-polly (sounds like monopoly). This market condition means that there are so few providers of the particular good or service that the events, actions, or circumstances of one seller affect the events, actions, or circumstances of the other sellers. Examples: Airline fares; oil prices; hardware costs; or possibly availability of spaghetti-cooking, COBOL-programming CCIEs who live in your neighborhood.

Cash and the Law of Diminishing Returns

One of my favorite economic laws is the Law of Diminishing Returns. It's basic stuff at first glance, but can really haunt a project manager if he's not careful. I know you're familiar with the Law of Diminishing Returns, but that guy from Sheboygan is also reading, so let me help him out.

Imagine that you have a wheat field. Wait, he's from Sheboygan. Imagine that you have a corn field and you know that you can get 100 trucks of corn out of the field. That's the most corn you'll ever get from the field. You also know that if you hire 10 guys to harvest the corn for you, they'll be done in 2 days. So you reason that if you hire 20 guys you'll be done in 1 day. So this must mean that if you hire 40 workers, all the corn will be harvested in half a day, right? Maybe, but if you continue to add workers to the field, a few things will happen:

Your yield-100 trucks of corn-remains the same no matter how quickly you harvest the corn.
Your profit will decline because you have to pay all those workers to harvest the corn for you. At some point, you may even be upside down on profitability because of the expense of labour.
The workers will become counterproductive because they'll start getting into each other's way.

So how does all this corn relate to an IT project?

The obvious answer is that you can't exponentially add labour to get a project done faster. And just because you add labour doesn't mean that the project will get done faster. (Have you ever had two programmers, two systems engineers, or even two Spanish-speaking, spaghetti-cooking, COBOL-programming CCIEs argue over how a task should be completed? The argument could go on for years before the work actually gets started.)

But the Law of Diminishing Returns also applies to the technology that you purchase. Have you ever bought an application that was so rich with features that the cost and time of learning the application was more than the returns from using the application? Or have you ever installed a massive powerhouse print server where many of the features of the OS go ignored? Or maxed out the RAM on a laptop that's only used for PowerPoint presentations and solitaire? When it comes to IT hardware, as with labour, project managers should procure only what's needed-not the maximum that the budget will allow.

Build or Buy?

Ah, one of the great arguments of all time. Should we buy it or should we build it? Well, it's probably not that great of an argument, but I'll bet you've been in some heated discussions on the value of either side of the debate. If not, let's start one now.

Sometimes, like it or not, it's more cost-effective to spend the cash and pay someone else to build the thing for you. Why? Your crew is busy doing other jobs, they don't have the competence to build the thing you need, or your organisation doesn't want to take the risk of creating the thing in-house. Lots of reasons.

Other times, like when your project team is lounging by the company pool sipping pinot noir and snacking on spaghetti, it's ideal to put them back to work building something. Again, there are lots of reasons why it may be better to build versus buy, or the other way around.

But sometimes it's purely a price decision. Here's the deal: Let's say that if your organisation builds a piece of software, it'll cost $45,000 to create and then $4,500 each month to support. Now, a vendor says they'll only charge you $23,000 to build the initial product, but they'll need $6,500 each month to support it as part of the deal.

Hmmm... so what's a project manager to do?

Maths.

Here's how it works: Take your build option of $45,000 and subtract the vendor's quote of $23,000. The difference is $22,000. Now take the monthly support fees of the vendor, $6,500, and subtract your lesser in-house fees of $4,500. The difference is $2,000.

Now, drum roll please, divide the initial out-of-pocket expense difference of $22,000 by the monthly support fees difference of $2,000 and you'll get 11. Eleven what?

Well, 11 in Blackjack means double down. Here it means that you can pay for the out-of-pocket expenses of creating the software in-house in 11 months. So, Copernicus, if your software creation will exist for less than 11 months, hire the vendor to do the work for you. If your solution will be around longer than 11 months, and price is the only factor, build the software yourself.

Taking Out a Contract

Contracts override everything: promises, email, secret handshakes. As long as they don't include illegal activities, contracts are backed by the U.S. legal system. A contract is what makes the deal a deal.

To get to the contracting activities, you need to create the procurement documents. The initial document is usually the statement of work (SOW), which describes the thing or service you want to buy. The SOW is provided to the vendor with an invitation to bid (IFB), which you probably also know as a request for quote (RFQ). The IFB and the RFQ are basically the same thing and are focused just on price, not ideas.

A request for proposal wants a price, but also suggestions and ideas on how the project work should be done. Proposals are more than just costs, they're a bit of consulting from the vendor.

In big-dollar contracts, you'll likely host a bidders' conference in which all vendors that want to create a proposal or bid will meet with you at once and ask questions concerning the SOW. This setup ensures that all the vendors have the same information on which to base prices and proposals.

Once you make a decision on which vendor to use, you go through negotiations, which lead to a contract. The contract-type selection might also be negotiated, but usually the type of work or goods being procured dictate the appropriate contract type. The following table lists the most common contract types and their attributes.

Contract Type	Description	Risk
Fixed fee	Fixed fee for the goods or services provided. Nice and easy.	The vendor has the risk of cost overruns.
Time and materials	You pay for the time and materials to complete the work.	Low risk as long as the contract includes a "not to exceed" (NTE) clause as a price cap.
Unit price	Fee per item or hour purchased. Sometimes these plans include incentives such as "Buy more items and the cost per item drops."	Low risk.
Cost plus (anything)	Cost of the goods and services plus a fee or percentage of the cost. Who uses these anymore? Not too many folks.	High risk for the buyer, as waste means you get to buy more and pay more.
Incentive fee contracts	These contracts award a bonus if the project is done early and can include penalties if the work is late or lacking in quality.	Usually low risk.

Bring Your Wallet

Procurement is, uh, big business. There are lots of details in procurement planning, the creation of procurement documents, bidder conferences, and in the contracting of the work. All organisations have their approach to procurement and contracting. You, the project manager, need to understand your organisation's approach and then follow the rules to get the stuff you need.

Now, if you'll excuse me, my Spanish-speaking, CCIE-certified, COBOL programmer has spaghetti ready. And I need to pay his invoice.

Having a Robust

2008-12-17T03:41:00.000-08:00

Having a Robust Governance Process

By Ron Rosenhead

So, you are organised, have identified the stakeholders as well as project risks (and you are actively managing both), you have planned the project and you are all ready to deliver.

But, have you developed a monitoring and control process for your project - an essential part of project management and work generally? One person who attended one of our project management training courses suggested that:

"A project goes over its deadline a day at a time, a day at a time, a day at a time. We have no excuse for not knowing. We should actively monitor and control our projects from business case through to closure."

This person had had some really bad experiences and wanted others who were on the course to avoid what he went through!

So, what can you put in place to ensure that you monitor and control your projects?

1. Loose v Tight Control

You need to decide, in conjunction with your sponsor (senior manager) the type of control that is appropriate for your project. Tight control is appropriate for high risk projects. You may want to mix the type of monitoring and control throughout the project. One you have decided on the appropriate type of control, ensure you develop a system that actually fits it. We have seen control processes that are supposed to be tight, but when examined are really loose.

2. Project Spend

You MUST have accurate project spend figures - whether it is a small low budget project or high capital expenditure. Ensure you create your own processes for capturing the figures if your internal system does not help! (See point 4 Planned v Actual below)

3. Tolerance

This is an interesting way of controlling projects. It works like this; in conjunction with the senior manager a figure is agreed - say 22.5% or 5% or 7.5%. You only report if you are over or under each activity.

Example 1: It is planned that activity twenty takes 15 days. A tolerance figure of 10% is agreed. The activity takes only 19 days to complete. You report this to the sponsor as you are over the tolerance figure of 10%.

Example 2: Activity 12 is planned for delivery at a cost of £4,000. The actual cost is £4,700. You report that activity 12 is over tolerance. You only report against those activities that are over or under tolerance.

4. Planned v Actual

Develop a simple chart which maps out the planned activity durations and costs. Plot against each the actual figures.

5. Reporting

Agree with senior managers how often and how you will report. NOTE: we advocate a one page report with agreed headings. In some projects you need to fulfil external reporting requirements. We suggest you familiarise yourself with these early in the life of the project.

6. Milestone Reports

Report against milestones. Develop a simple milestone reporting chart. Ensure when someone reports they are off schedule against a milestone they have a recovery plan to bring it back on target!

7. Project Changes

Develop an agreed process to deal with project changes. Few projects go through their life cycle without change. But, you must control the changes rather than allowing them to control you! How? Use a simple change control sheet. Record the type of change and the impact. Formally agree changes with the project sponsor if the change impacts on the project budget or the project objectives.

8. Meetings

Have agreed agendas and agreed durations for each project meeting. Ensure you produce ACTION POINTS which are circulated very soon after the meeting.

When should you put start putting in place the project monitoring and control process? We suggest as early as possible. It should be discussed at the time the business case is agreed. Without a process in place early then you will not have a robust process and the project could well stray!

Project management needs robust monitoring and control processes. As one delegate on a training programme put it, "anything to prevent project creep!"

Benefits of Merging

2008-12-17T03:40:00.000-08:00

Get Maximum Benefits of Merging Top-down and Bottom-up Project Management

Get the PDF Version

By Andrew Filev

Nowadays, the bottom-up approach to management is becoming more and more popular. More and more, organisations are abandoning the top-down management style. Among them are the New York Times, Tribune Co., Ernst & Young and many others. Even the world biggest corporations, such as Toyota and IBM, are trying to implement bottom-up management style elements in some of their departments. However, managers are still arguing over which approach is more beneficial for organisations. To understand the reason for the ongoing changes in management processes, we need to compare the two management styles.

New York Times Case: Problems Caused by the Top-down Approach

The essence of the top-down approach is that all the directions come from the top. The top management establishes project objectives and provides guidelines, information, plans and funding processes. The manager clearly communicates his expectations to each project team member. To advocates of this approach, ambiguity opens the door for potential failure, so managers should be as specific as possible when communicating their expectations.

One of organisations applying a top-down management style was the New York Times, a leader in the newspaper industry. According to American Journalism Review, several years ago, the Times' executive management felt that what they were doing was not able to create a vibrant workplace and a successful enterprise. The power was centralised. Masthead editors had overall control. The editors naturally introduced the same management pattern in the projects for which they were responsible. Project managers' emotions and opinions influenced all the project decisions. As a result, people felt that their voices didn't count, that they weren't listened to. Journalists were not morally motivated to do their jobs. There was no effective collaboration between them. The managing executives then realised that more freedom should be given to the teams. It took a lot of time to introduce bottom-up style elements to management. However, it was worth the time and effort, as the collaboration is now enhanced, and teams work more productively.

Similar problems can be observed in many organisations with a traditional management style. Practice shows that the top-down approach can reduce productivity and cause bottlenecks or so-called lockdowns. Lockdown gives a project manager as much control over his team as possible. This inflexibility can cause unnecessary pain and slow down the project work.

Is the Bottom-up Approach Better?

The factors mentioned above can lead the best projects to failure. That is the reason why many organisations, such as the New York Times, try to implement a bottom-up management style or at least some of its elements. Bottom-up management proactively seeks the input of the team in the project executing process. Employees are invited to participate in every step of the process. The team as a whole agrees on the course of action. This approach allows managers to communicate goals and value, e.g. through milestone planning. Then team members develop personal to-do lists, which include the steps necessary to reach the milestones on their own. It is up to them to choose the methods and ways to perform their tasks. The advantage of this approach is that it empowers team members to think more creatively. They know that their initiatives are appreciated. The team members' motivation to work and make the project a success is increased. The planning process flows significantly faster, as it is facilitated by a number of people. The to-do lists of all the team members are collected into the detailed project master plan. Schedules, budgets and results are transparent. The project manager makes all the issues clear to avoid as many surprises as possible.

However, despite all of the enumerated advantages, the bottom-up approach is not the perfect solution. Sometimes it lacks clarity and control. A lot of experts agree that a bottom-up style alone will not make your projects flourish. The wisest thing for a project manager to do would be to take the best practices from the two approaches and try to create a hybrid method.

Leveraging Advantages of the Two Styles

Is it possible to successfully introduce the best bottom-up practices to an organisation by utilising traditional tools? Traditional project management software was originally designed with the top-down approach in mind. Traditional applications are not meant for bottom-up management. They are complex and hard to master. These applications are focused on the project manager and make him the major link in project communications. Team members very often do not have access to the project plan and cannot make contributions. The employees e-mail their updates to the project manager in disconnected files. The project manager then has to collect all the data and put the information manually into the project plan. Then he has to communicate the changes to the corporate executives. The misalignment between the bottom-up best principles and the old tools may cause situations when the project manager's talents are buried by the routine operations. Sometimes project managers just do not have time for leadership.

The old methods of how people share and receive information have been radically transformed in recent years. Now there are more means for the successful implementation of the bottom-up management best practices. These are Enterprise 2.0 technologies, such as wikis, blogs and collaboration tools. The new technologies come into organisations and change the old way of managing projects. They turn traditional project management into Project Management 2.0 and bring new patterns of collaboration, which are based on collective intelligence. Collective intelligence is a collection of valuable knowledge from different fields that each project team member is an expert in. This knowledge is now successfully collected and shared in a flexible, collaborative environment brought by second-generation project management software. The project manager is the one to conduct the work and choose the right direction for the project development, based on the information received from individual employees.

The role the project manager plays in the project changes. Project Management 2.0 software helps him create complete delegation. People become less dependent on the manager as a to-do generator. The project manager turns from a taskmaster into a project leader who facilitates the team communications, provides a creative working environment and guides the team. He becomes a visionary who can leverage the team strengths and weaknesses and adjust project development to the external changes.

The second-generation tools allow project managers to merge the advantages of the two initial management approaches. These applications let you combine control and collaboration, clarity of project goals and visibility of internal organisational processes.

Thousands of companies now report that bottom-up project management, implemented with the help of Enterprise 2.0 tools, improved their business performance. Among them are Bell Canada, Sun and Yahoo. These corporations created their corporate blogs to streamline project communications. Even giants, such as IBM, realise the benefits of allowing contributors to have a more active hand in how collaborative work is organised.

Democratising project management is never an end in itself. The primary goal is always to find ways to make project management and project collaboration more efficient. New technologies applied to projects offer us the powerful ability to make projects more successful and teams more productive. With the help of new-generation tools, projects can be delivered much faster, and this is to everyone's benefit.

MakeEffective

2008-12-17T03:38:00.000-08:00

Let's Make Those Project Meetings More Effective

By Ron Rosenhead

I was trying to get hold of the project manager. Or rather he was trying to get hold of me. However, I had tried 3 times already so I sent him an email knowing it would sink to the bottom of the pile.

I got to thinking that it wasn't just this project manager who always seemed to be in meetings. Several people I have been trying to get hold of always seem to be in back to back meetings.

Project Agency has been collecting statistics for several years. Some 1,120 people have completed our questionnaire and one of the questions is quite revealing:

"Project meetings are collaborative events which look at achievements not past failures." The percentages are shown below:

Strongly Agree: 1.3% (15 people)
Agree: 25.6% (289 people)
Disagree: 57.3% (648 people)
Strongly Disagree: 12.6% (143 people)
Don't Know: 3.2% (36 people)

Not very good stats are they? Interesting that 36 people do not know how effective their meetings are!

So, what can be done? Well, here are some golden rules for project management meetings (and meetings in general):

Rule 1: Ensure you have the right people there. May seem obvious but how many meetings go ahead with the wrong people there and the right people "on the way" or a key stakeholder not even invited?

Rule 2: Have an agenda for each meeting and against each item put a time (the length of time the item will take). Ensure you stick to the stated time.

Rule 3: Have a clear objective. Is it to receive a highlight report, or to prepare a highlight report. Is it to review project progress based on milestones, or develop part of your plan, or all of these. If you go off agenda/objective here is a quick tip. Everyone is given a coloured card (any colour as long as they are the same). If a person goes off the agenda or is rambling on you put up your card. It works, try it.

Rule 4: Summarise before moving on to the next point. This ensures everyone is clear about what has been agreed or said.

Rule 5: Have a stand up meeting. Yes, stand up meetings i.e. NO chairs - speeds up the meeting and really does focus attention.

Rule 6: Papers, we are supposedly in the era of a paperless office. Ensure the meeting is not bogged down with papers. Use highlight reports to cut down paper and speed up the meeting.

Rule 7: Rules, what rules have you agreed? I know of one person who said that if the start time for a meeting was 3pm then no one was allowed in after this time! What are your rules for your meetings and does everyone know about them. Useful to use your cards here (rule 3).

Rule 8: Train, yes you can train people to be better in meetings. Chairing a meeting, contributing via appropriate questions, listening, preparing an agenda, these are all areas a person can be trained and developed. Call us or e mail events@projectagency.com for more information.

And finally (Rule 9) - review how successful your meetings have been. If you set out an hour and a half for a meeting and it has only lasted an hour then you should be saying well done (provided the meeting met its objective). If it lasted 2 hours then you should review why to stop it happening again.

Help make sure your meetings go well and help make the scores above better, much better.

21 Success Tips

2008-12-17T03:37:00.001-08:00

21 Project Management Success Tips

By Karl Wiegers, Ph.D

Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and unachievable demands from unreasonable people. Project management is people management, technology management, business management, risk management, and expectation management. It's a juggling act, with too many balls in the air at once.

Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from painful experience. Coaching and survival tips from people who have already done their tour of duty in the project management trenches can save you from learning such lessons the hard way. Here are 21 such tips for success, which I've learned from both well-managed and challenged projects. The tips are organised into five categories:

Laying the groundwork for success.
Planning the project.
Estimating the work.
Tracking your progress.
Learning for the future.

Together, the practices in these five categories define a project management control system that can help your project deliver on expectations. Keep these suggestions in mind on your next project, recognising that none of them is a silver bullet for your project management problems.

Laying the Groundwork

Tip #1: Define project success criteria

At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals. Some examples are:

Increasing market share by a certain amount by a specified date.
Reaching a specified sales volume or revenue.
Achieving certain customer satisfaction measures.
Saving money by retiring a high-maintenance legacy system.
Achieving a particular transaction processing volume and correctness.

These business goals should imply specific project success criteria, which should again be measurable and trackable. They could include achieving schedule and budget targets, delivering committed functionality in a form that satisfies customer acceptance tests, complying with industry standards or government regulations, or achieving specific technological milestones.

Also, keep your eye on team member job satisfaction, sometimes indicated by staff turnover rate and the willingness of team members to do what it takes to make the project succeed. The business objectives define the overarching goal, though. It doesn't matter if you deliver to the specification on schedule and budget if those factors don't clearly align with business success.

Remember that not all of these defined success criteria can be your top priority. You'll have to make some thoughtful trade-off decisions to ensure that you satisfy your most important priorities. If you don't define clear priorities for success, team members can wind up working at cross-purposes, leading to frustration, stress, and reduced teamwork effectiveness.

Tip #2: Identify project drivers, constraints, and degrees of freedom

Every project must balance its functionality, staffing, cost, schedule, and quality objectives [Wiegers, 1996]. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. There's bad news: not all factors can be constraints and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for increased functionality, staff turnover, and other realities.

A "flexibility diagram" such as that shown in Figure 1 visually depicts your constraints, drivers, and degrees of freedom. A constraint gives the project manager no flexibility in that dimension, so it is plotted at the zero value on its axis. A driver yields a small amount of flexibility, so its point is plotted a bit higher than zero. Degrees of freedom provide varying degrees of latitude. They represent parameters the project manager can adjust to achieve the project's success drivers within the limits imposed by its constraints. Connecting the five plotted points creates an irregular pentagon. The smaller the area inside the pentagon, the more constrained the project is.

I once heard a senior manager ask a project leader how long it would take to deliver a planned new large software system. The project leader replied, "Two years." The senior manager said, "No, that's too long. I need it in six months." The project leader's response was simply, "Okay," despite the fact that nothing had changed in the few seconds of that conversation to make the six-month target achievable. A better response would have been to negotiate a realistic outcome through a series of questions such as the following:

How critical is the six-month target? Does something drastic happen if we don't deliver in six months [schedule is a constraint], or is that just a desirable target date [schedule is a driver]?
If the six months is a firm limit, what subset of the requested functionality do you absolutely need delivered by then?
Can I get more people to work on it? [staff is a degree of freedom].
Do you care how well it works? [quality is a degree of freedom].

Figure 1. A flexibility diagram for a project that is staff-constrained and schedule-constrained, with cost being a driver, and quality and features being degrees of freedom.

Tip #3: Define product release criteria

Early in the project, decide what criteria will indicate whether the product is ready for release. Possible release criteria might include the following:

There are no open high-priority defects.
The number of open defects has decreased for X weeks and the estimated number of residual defects is acceptable.
Performance goals are achieved on all target platforms.
Specific required functionality is fully operational.
Quantitative reliability goals are satisfied.
X% of system tests have been passed.
Specified legal, contractual, or regulatory goals are met.
The optimum marketplace time to release has arrived.
Customer acceptance criteria are satisfied.

Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what "quality" means to your customers. Decide early on how you will tell when you're done, track progress toward your goals, and stick to your guns when confronted with pressure to ship before the product is ready for prime time.

Carefully consider your target market segments when deciding on release criteria [Rothman, 1999]. The early adopters and enthusiasts have a higher tolerance for defects than do the pragmatic early majority of customers or the conservative late majority. In contrast, time to market and innovative features or technology usage are most important to the early adopters.

Tip #4: Negotiate achievable commitments

Despite pressure to promise the impossible, never make a commitment you know you can't keep. Engage in good-faith negotiations with customers, managers, and team members about goals that are realistically achievable. Negotiation is required whenever there is a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates. Principled negotiation involves four precepts [Fisher, 1991]:

Separate the people from the problem.
Focus on interests, not positions.
Invent options for mutual gain.
Insist on using objective criteria.

Any data you have from previous projects will help you make persuasive arguments, although there is no real defence against truly unreasonable people.

I once met with an aggressive and intimidating senior manager to discuss our department's software process improvement plans. Jack was eager to see our department achieve CMM Level 2 by July of 1996. My process improvement group had carefully studied the problem and estimated that the end of 1997 was the earliest date that was even remotely feasible. After some debate, Jack grudgingly agreed to the end of 1996, but I regarded even that goal as pure fantasy. After additional discussion, I finally said, "Jack, I'm not going to commit to the end of 1996." I don't think anyone had ever told Jack he wouldn't make a commitment that Jack demanded. He wasn't sure what to say next. Jack eventually agreed to the target date to which I was willing to commit.

Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialise, or new requirements are added. No one likes to have to modify his commitments. However, if the reality is that the initial commitments won't be achieved, let's not pretend that they will up until the moment of unfortunate truth.

Planning the Project

Tip #5: Write a plan

Some people believe the time spent writing a plan could be better spent writing code, but I don't agree. The hard part isn't writing the plan. The hard part is actually doing the planning-thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analysing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project. Today's multi-site and cross-cultural development projects demand even more careful planning and tracking than do traditional projects undertaken by a co-located team.

A useful plan is much more than a schedule or work breakdown structure of tasks to perform. It also includes:

Staff, budget, and other resource estimates and plans.
Team roles and responsibilities.
How you will acquire and train the necessary staff.
Assumptions, dependencies, and risks.
Descriptions of, and target dates for, major deliverables.
Identification of the software development life cycle that you'll follow.
How you will track and monitor the project.
Metrics that you'll collect.
How you will manage any subcontractor relationships.

Your organisation should adopt a standard software project plan template, which can be tailored for various kinds of projects. An excellent starting point is IEEE Std 1058-1998, the "IEEE Standard for Software Project Management Plans" [IEEE, 1998]. This standard describes a comprehensive template, sufficient for the largest projects. Study this template to see what sections would make sense for the types and sizes of projects that you work on.

If you commonly tackle different kinds of projects, such as major new product development as well as small enhancements, adopt a separate project plan template for each. Avoid overburdening small projects with excessive documentation that adds little value. The project plan should be no any longer nor more elaborate than necessary to make sure you can successfully execute the project. But always write a plan.

Tip #6: Decompose tasks to inch-pebble granularity

Inch-pebbles are miniature milestones (get it?). Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking. Select inch-pebbles of a size that you feel you can estimate accurately. I feel most comfortable with inch-pebbles that represent tasks of about 5 to 15 labour-hours, or about one to three days in duration. Overlooked tasks are a common contributor to schedule slips, so breaking large problems into small bits reveals more details about the work that must be done and improves your ability to make accurate estimates.

You can track progress based on the number of inch-pebbles that have been completed at any given time, compared to those you planned to complete by that time. Defining the project's work in terms of inch-pebbles is an aid to tracking status through earned value analysis [Lewis, 2000]. The earned value technique compares the investment of effort or dollars that you've made to date with progress as measured by completed inch-pebbles.

Tip #7: Develop planning worksheets for common large tasks

If your team frequently undertakes certain common tasks, such as implementing a new object class, executing a system test cycle, or performing a product build, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Using standard worksheets will help the team members adopt common processes that they can tune up as they gain experience. Tailor the worksheets to meet the specific needs of individual projects.

Tip #8: Plan to do rework after a quality control activity

I've seen project task lists in which the author assumed that every testing experience will be a success that lets you move into the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. Base your estimates of rework time on previous experience. For example, you might have historical inspection data indicating that, on average, your developers find 25 defects per thousand lines of code by inspection and that it costs an average of 40 minutes to fully repair each code defect. You can crunch these kinds of numbers to come up with average expected rework effort for various types of work products. If you don't actually have to do any rework after a test, great; you're ahead of schedule on that task. Don't count on it, though.

Tip #9: Manage project risks

If you don't identify and control project risks, they will control you. A risk is a potential problem that could affect the success of your project, a problem that hasn't happened yet, and you'd like to keep it that way [Wiegers, 1998]. Risk management has been identified as one of the most significant best practices for software development [Brown, 1996]. Simply identifying the possible risk factors isn't enough. You also have to evaluate the relative threat each one poses so you can focus your risk management energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialise into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities are not effective. Suppose you are concerned that your top developer might move to Australia to be with her new boyfriend. Consider the following actions:

Pay her more money, offer to hire the boyfriend, or give her more vacation time to fly to Australia periodically (reduces probability).
Keep her on as a telecommuting employee or contractor, have her document her work, or have her impart her specialised knowledge to other employees (reduces impact).
Line up a consultant or contract specialist to replace her if she leaves anyway (contingency plan).

A risk list does not replace a plan for how you will identify, prioritise, control, and track risks. Incorporate risk tracking into your routine project status tracking. Record which risks materialised and which mitigation actions were effective for reference on future projects.

Tip #10: Plan time for process improvement

Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you'll have to invest some time in process improvement [Wiegers, 1999]. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don't allocate 100 percent of your team members' available time to project tasks and then wonder why they don't make any progress on the improvement initiatives. Some process changes can begin to pay off immediately, whereas you won't reap the full return on your investment in other improvements until the next project. View process improvement as a strategic investment in the sustained effectiveness of your development organisation. I liken process improvement to highway construction: it slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput greater.

Tip #11: Respect the learning curve

The time and money you spend on training, reading and self-study, consultants, and developing improved processes are part of the investment your organisation makes in project success. Recognise that you'll pay a price in terms of a short-term productivity loss when you first try to apply new processes, tools, or technologies. Don't expect to get fabulous benefits from new software engineering approaches on the first try, no matter what the tool vendor's literature or the methodology consultant's brochure claims. Instead, build extra time into the schedule to account for the inevitable learning curve. Make sure your managers and customers understand the learning curve and accept it as an inescapable consequence of working in a rapidly changing, high-technology field.

Estimating the Work

Tip #12: Estimate based on effort, not calendar time

People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labour-hours) associated with a task, then translate the effort into a calendar-time estimate. A 20-hour task might take 2.5 calendar days of nominal full-time effort, or 2 exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. The translation of effort into calendar time is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears. If you keep track of how you actually spend your time at work, you'll know how many effective weekly project hours you have available on average [Wiegers, 1996]. Typically, this is only about 50 to 60 percent of the nominal time people spend at work, far less than the assumed 100 percent effective time on which so many project schedules are planned.

Tip #13: Don't schedule multi-tasking people for more than 80 percent of their time

The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multi-tasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so she could do five of them at once. In reality, she'll be lucky if she can handle three such tasks. Some people multi-task more efficiently than others. If some of your team members thrash when working on too many tasks at once, set clear priorities and help them succeed by focusing on just one or two objectives at a time.

Tip #14: Build training time into the schedule

Estimate how much time your team members spend on training activities annually, and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way. Recognise that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company's time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the knowledge is put to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Tip #15: Record estimates and how you derived them

When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is instinctively skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organisation can use.

An effective group estimation technique is the Wideband Delphi method [Wiegers, 2000]. Wideband Delphi builds on the principle that multiple heads are better than one. The Delphi estimation method asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Figure 2 illustrates the Wideband Delphi process flow. The outputs from the process include a complete list of project and quality-related tasks and an estimate for each task, in whatever units the team chose (such as dollars, weeks, or labour-hours). Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Delphi method more reliable than simply asking a single individual for his best guess.

Figure 2. The Wideband Delphi process flow.

Tip #16: Use estimation tools

Many commercial tools are available to help you estimate entire projects. Based on large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They'll also help you avoid the "impossible region," combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of "cost drivers" you can adjust to make the tool more accurately model your project, based on the technologies used, the team's experience, and other factors. Over time, you can calibrate the tool with your own project data to make it an even more reliable predictor of the future. A good tool to try is Estimate Pro from the Software Productivity Center (www.spc.ca). Others include KnowledgePlan (www.spr.com), SLIM (www.qsm.com), and Cost Xpert (www.costxpert.com). You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Tip #17: Plan contingency buffers

Projects never go precisely as planed. The prudent project manager incorporates budget and schedule contingency buffers (also known as management reserve) at the end of major phases to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialise and build that projected risk exposure into your schedule as a contingency buffer. Even more sophisticated is the use of critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer [Zultner, 1999].

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgement of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. The reality on most projects is quite different. I'd rather see us deal with reality, however unattractive, than to live in Fantasyland, which leads to chronic disappointments.

Tracking Your Progress

Tip #18: Record actuals and estimates

Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, "If you write down what actually happened today, that becomes historical data tomorrow." Unless you record the actual effort or time spent on each task and compare them to your estimates, you'll never improve your estimating approach. Your estimates will forever remain guesses. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in units of lines of code, function points, classes and methods, GUI screens, or other units that make sense for your project.

Tip #19: Count tasks as complete only when they're 100 percent complete

We give ourselves a lot of partial credit for tasks we've begun but not fully completed: "I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I'm probably about 60 percent done." It's difficult to accurately assess what fraction of a sizable task has actually been done at a given moment. One benefit of using inch-pebbles for task planning is that you can break a large activity into a number of small tasks and classify each small task as either done or not done, nothing in between. Your project status tracking is then based on the fraction of the tasks that are completed, not the percent completion of each task. If someone asks you whether a specific task is complete and your reply is, "It's all done except...", it's not done! Don't let people "round up" their task completion status; use explicit criteria to tell whether a step truly is completed.

Tip #20: Track project status openly and honestly

An old riddle asks, "How does a software project become six months late?" The answer is, "One day at a time." The painful problems arise when you don't know just how far behind (or, occasionally, ahead) of plan the project really is. Create a climate in which team members feel it is safe for them to report project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that sometimes arises from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what's done and what isn't, what tasks are falling behind their estimates and why, and what problems and issues remain to be tackled. The five major areas of software measurement are size, effort, time, quality, and status. Remember the cardinal rule of software metrics: metrics data must never be used to punish or reward individuals for their performance.

Learning for the Future

Tip #21: Conduct project retrospectives

Retrospectives (also called postmortems or post-project reviews) provide an opportunity for the team to reflect on how the last project or the previous phase went and to capture lessons learned that will help enhance your future performance [Kerth, 2001]. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn't go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors for which you should be alert on the next project.

Conduct retrospectives in a constructive, honest atmosphere. Don't make them an opportunity to assign blame for previous problems. Capture the lessons learned from each review and share them with the entire team and organisation, so all can benefit from your painfully gained experience. I like to write lessons learned in a neutral way, such that it isn't obvious whether we learned the lesson because we did something right or because we made a mistake.

These 21 project management tips won't guarantee success, but they will help you get a solid handle on your project and ensure that you're doing all you can to make it succeed in an unpredictable world.

How to Report

2008-12-17T03:36:00.001-08:00

How to Report Status on a Project

By Rob Redmond

Your boss has asked you to take the lead on a project in your company. Maybe you are a project manager, or maybe you are not. One thing is certain. Very few people know how to report status on a project, even when they are expert project managers. The basic problem? Most people do not understand the perspective of a manager who is being pressed for information about a big project. Here are some basic rules of reporting status that you can use to further your reputation as someone who knows how to keep management and the project team informed and drive a project to success.

The Management Perspective

If your project is important, your boss will be pressed hard to keep his superiors informed of its progress. Smart managers consume status on important projects voraciously. Excellent status reporting means that managers are fully informed of your projects health and overall direction without having to get involved themselves. There is particular information your boss needs in order to show her boss that she is on top of things and able to run the show effectively. Provide this information in a way your boss can consume it on a regular basis, and you will fall upstairs so fast your head will spin.

Even on relatively less important projects, effective status reporting allows your boss to spend only a few seconds skimming your report to determine what sort of progress you have made.

Excellent status creates clarity from confusion. Your job as the manager of a project is to take a swirling, chaotic cloud of information and distil it down into its most basic elements and then present them so that hundreds and thousands of hours of work can be understood in 30 seconds.

To write excellent status, you must understand:

The three components of status.
How to write brief details.
What key data is needed by management.

Three Components of Status

There are three major components to reporting project status:

Overall: We need to see the overall project health. As managers, we want to be able to detect a project in trouble. We also want to help make that determination sometimes. You might not know everything we know despite our best efforts to communicate. Your project might not be as healthy as you think it is.
Milestones: Your project has major accomplishments which must be completed by specific dates. We managers want to see which milestones are complete, which ones are in progress, and which ones are coming up next. This allows us to analyse the schedule and decide to either feel comfortable with it or challenge it.
Issues: Your project also probably has one or more obstacles to completion which have been discovered. We'd like to see brief details about each issue so that we can make a decision about whether or not to step in and help if necessary.

Organising Your Status

Just as you would clean a kitchen by starting up high and working your way down ultimately to the floor, project status is best when it starts off with the highest levels of detail and works it way down to lower and lower levels.

Thus:

Overall project health comes first. If I like what I see here, I can stop reading the rest. Major milestones follow overall project health. If I don't like the project health, or if I am in need of further details, I can read a little further and check out the scheduled dates we are driving toward and your progress on them. Issues may be holding up those dates, so when I see a problem in your project schedule, I can read further and see what it is. Really slick project managers report the issues in priority order showing the issue causing the most jeopardy to progress first.

Brief Details

Your job is to report on the details of your project in concise, crisp status that we can consume rapidly without having to spend much effort on it. It might take you thirty minutes to write your status, but always remember that your manager does not have thirty minutes to spend reading it. Your manager realistically only has about 30 seconds to consume your status as they may have 30, 40, 100, or even exponentially more projects for which they are responsible.

"Brief Details" may seem oxymoronic to a project manager, but to a supervisor with a team of project managers, it is not. There is enormous value in a project manager who can report status without narrative. My recommendation is that you write as though you were creating an old-fashioned telegram. More information about how to do that is coming.

Brief Details?

How can you provide details without being long-winded? It is a formidable task that most never master, but it is not impossible. Here are some suggestions:

Write in bullets, not in prose. There shall be no paragraph anywhere in your status.
Avoid unnecessary use of titles and colons. We can see that 7/4/2008 is a date. Writing "date: 7/4/2008" does not tell us anything that "7/4/2008" does not.
Reduce, reduce, and reduce some more. Do your best to shorten all expressions and sentences.
Avoid adverbs (really, very, much) and avoid adjectives (good, bad, ugly).

Key Data

Management will need certain data from you in order to see overall health, performance against milestones, and the threat that project issues present. For overall project health, these data points might include:

The project's name
The project identification number if your company uses a tool to store projects.
The overall project health (red yellow green - more on this in a future article).
The % complete you expected to be at today (planned completion).
The % complete you are actually at.
The number of days behind or ahead against the plan.
The number of blocking issues you face (more about this later in this article).
The number of "normal issues" you face.

These data elements should provide a sound overview of project health for the average executive who is not details minded and is not interested in getting more involved in your project.

If I am your supervisor, I need to see more than just the overall health of the project. I also want to see where we are against certain milestones so that I can make a decision about whether or not to get more involved. One of the hardest things a manager has to do all day is decide whether to give you more room or get into your work with you. We don't want to carry your work for you, but we also don't want you to fall flat on your face.

Providing project milestones is helpful in this regard. It lets us see your schedule at a high level, determine if the schedule is acceptable as it stands, and predict pitfalls you might face down the road.

Milestones have six components:

The milestone name.
The percent complete of the milestone.
The planned start.
The planned finish.
The actual start.
The actual finish.

Some people like to provide red, yellow, green (RYG) status for each milestone in their project. I don't believe that adds any value. Of course the completed tasks are green. They are complete! All following milestones have the same status as the current milestone, so there is no point in differentiating them. The RYG status of the whole project is all that is necessary.

It's best to start with the earlier tasks first and the final delivery date at the bottom. If you list them haphazardly, you will create more confusion than clarity.

Issue Management

The final portion of your status report is to list the major issues your project faces. Important data that we need on your issues:

Ticket number: if there is a ticketing system, give us a link to the ticket or the number of the ticket.
Issue name: this should be very descriptive and brief.
Date and time reported: we need this to see aging. The older an issue is, the more likely someone is going to get in trouble for not solving it faster.
Priority or severity of the issue: your issue is mega-important if it is a "blocking issue." If the problem is stopping the project from moving forward and is single-handedly responsible for endangering the delivery date, it is a blocking issue and is very important. If the problem is just another bug in some software that will be resolved in short order, it is not as important.
Who has it: the name of the person who currently owns driving this issue forward.
ETA: Managers are like children and always want to know when they are going to get something. "Are we there yet? Are we there yet?" Provide a time and date for when the issue will be resolved. If you cannot, then provide a time and date for when you will get to the next step in the issue resolution process. If you cannot do that, then provide an ETA for your next updated status on the issue.
Current Activity: What is currently being done to resolve this issue? Are you firing up a conference call? Are you calling out for reinforcements from a particular group? What is being done to mitigate? Are there alternatives?

Expected Results

If you produce really great status on a project and provide it often enough and to the right people, which are great topics for future articles, you should expect one of two results. Either management will become very quiet and not engage with you very much, which usually means they feel you are on top of the project and are capable of operating without their intervention, or they will increase their communications with you in order to ferret out further details and determine if they need to intervene.

Either result is better than the alternative: Management asking you for status. Your job as a project manager is to create clarity from confusion for the project team and for management. Essentially, the job is one of analysis and communication. If management is asking you for the status, either you are not sending it to the right people, you are not sending it often enough, or you are not sending a good status report.

Management should be able to passively absorb your status without having to reach out to you to find out where things are at. The pace at which you send it, the audience you select, and the content of your communications should be available to them easily and quickly.

A project manager that can status a project skillfully and briefly is a rare find. It should not be necessary to create colorful slide shows or multi-page documents in order to provide really great status reports. Many go that route and drown management in errata. Narratives and prose are always unwelcome in status reports, and yet so many write as though they were authoring a novel and create a report that management must spend inordinate amounts of time with in order to get what they need. Others fail to provide enough information at all, or worse, they provide status irregularly or rarely.

In all of the project management training and certification systems available today, almost none teach how to report the current state and next steps of a project. Learn to status your projects effectively and you have a competitive edge that goes beyond the standard project management toolkit.

How to Deliver

2008-12-17T03:35:00.001-08:00

How to Deliver Project Status

By Rob Redmond

In a previous article, I recommended a way to report on a project's status briefly and yet in a way that provides management with the level of detail that they need in order to interpret the overall health of the project. In this article, I give some recommendations as to how to deliver that status to management and the project team that you will hopefully find to be very effective.

Status is project management communication, and any channel of communication available to you is a possible delivery method for status. There are two basic kinds of delivery method: presentation and verbal. When you give status in presentation format, you have a reference document that you are reviewing with a group of people. When you give status verbally, you are delivering it without much preparation and without referring to a common document.

Verbally or in presentation format, you can deliver status:

Face to face
Over the phone, one on one
On a conference call
By instant messenger
In e-mail

Face to Face

Face to face status reports could happen in a staff meeting, but more likely might occur in a hallway or when you stop by your boss's office to check in on another topic. "So, how is Project X coming along?"

When you deliver status verbally, stick the recommended format. First, provide overall information such as project health, % complete, % target complete, number of days ahead or behind schedule. Tell what milestone you are in, and what next steps are. If asked, go into a very crisp description of the most important issue that is outstanding on the project. The biggest point to remember about verbal status is to keep it concise. Practice delivering status verbally in your mirror, and try to give the entire project status in less than 30 seconds. More than that, and you risk irritating your manager with unnecessary details, or, more likely, you risk rambling on and on about details that are not the right details.

Whether you are in a conference room or in your boss's office, the ability to provide crisp, fresh project status verbally can mean the difference between being seen as a project management genius and a village idiot. Wandering, verbose reports on projects, which provide seemingly random and extensive irrelevant details are a frequent source of irritation for management.

Over the Phone

The same rules apply over the phone. Consider a conference call to be the same thing as an in person meeting around a table. A one on one call is the equivalent to any face to face meeting. Be brief. Since you are not in person, you can use a script or a one page status report for a reference source without revealing that you are doing so.

Instant Messenger

Most IM programs don't really allow for graphics, so hopefully you have a text status which is very brief that you can paste into IM on request when your boss sends a quick message over asking after a particular project. Have it ready to go, in writing, and pop in the overall information first. If they press on, provide milestones in another message and your top issue last.

E-mail

E-mail is by far the most powerful tool for providing project status. There is one big mistake that separates e-mail from all other communication channels. E-mail provides the ability to attach documents, so many project managers will attach one or more files, usually a combination of documents such as a presentation with multiple slides and a spreadsheet with multiple tabs.

Folks, the truth is that most managers will never open up your attached documents in e-mail. If the status is not in the actual body of the e-mail message, it might never be seen, which is why you are called or IM'd for project status.

Why?

E-mail inboxes become clogged very easily. The higher up the chain of command you climb, the more e-mail you receive. The more you receive, the less time you have to process each message. The more content in the message, the less likely you are to bother attempting to process the message. That and the fact that e-mail attachments tend to indicate the opposite of crisp status. Instead, the status on your project is probably a huge pile of data that the manager does not want to sort through to figure out the current state.

Boil it all down to the body of the e-mail. Make it brief. Make it readable on a Blackberry or other smart phones. Do not flood management with information, and yet do not leave them asking questions.

The subject line of your e-mail should be very relevant to the project. Put the project's official name in the subject line along with the project ID number from your tracking system, if there is one. This helps management sort your status reports easily in their inbox after they have filed them away. Try to use the same subject from one e-mail report to the next.

How Often Should You Send Status

Send status reports in e-mail as often as the project events require. If the project is green and not on your boss's top ten list, then you might never send project status upstairs as your project cruises to easy completion without management assistance. If you have a high visibility project with a gigantic budget, a massive cross-functional project team, and multiple executive participants, then your status should appear in e-mail to all participants and your boss regularly.

Note that I said to include your boss. Never send project status to your boss's peers or superiors in other departments without copying your boss. If your boss hears about your project from other teams by surprise due to your failure to include her on status reports, you'll find yourself on your boss's list of people to educate about status reporting. No manager likes to be blindsided with news about a project that is being managed in their own department.

If the project is important enough and in enough trouble to invite such scrutiny, status reports may be needed daily. They may even escalate to hourly in some extreme cases.

Don't fall out of your chair in shock just yet! Status reports may be asked for every 30 minutes in certain fast-paced environments.

Sending out effectively organised status which is well composed allows management to quickly consume what they receive passively rather than working long hours to call around, send messages, and slowly gather up information. This allows for the avoidance of much frustration on management's part and makes you a project manager worth your weight in gold.

The Blending

2008-12-17T03:34:00.001-08:00

The Blending of Traditional and Agile Project Management

By Kathleen Hass

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognisable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort.

Traditional project management assumes that events affecting the project are predictable and that tools and activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.

Today, business processes are more complex and interconnected than ever before. Additionally, they reject traditional organisational structures and involve complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers, partnerships and even competitors. Through these alliances, organisations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.

For years, economists have been warning that success in a global marketplace is contingent upon the capability to produce small batches of tailored products on a tight schedule to meet growing demands in emerging markets. Looking at results the past project performance record is troubling:

$80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)
25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
50% are rolled back out of production (Gartner)
40% of problems are found by end users (Gartner)
Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)
60% - 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
Nearly two thirds of all IT projects fail or run into trouble. (See Figure 2 for the results of the 2006 CHAOS Survey.)

Improving these performance records is a goal for any organisation. However, if traditional project management is somewhat ineffective, it's time to examine other methods of designing and delivering projects.

Agile Project Management

For projects involving a significant software component, traditional project management can be somewhat ineffective since the requirements are elusive, volatile and subject to change. An alternative approach, Agile Project Management (APM), is emerging in the industry. APM is a highly iterative and incremental process, where developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritise functionality.

Agile methods are used when these conditions are present: project value is clear; the customer actively participates throughout the project; the customer, designers, and developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall vs. formal documentation) is acceptable. See figure 3

The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product as requirements come into view. APM requires a dedicated full-time project team that includes a customer or end user, where team members work from the same location.

The Agile Project Management Environment

APM development is conducted collaboratively, with a small co-located team. This core team usually consists of two developers who write code in pairs (for quality control), the customer/end-user, IT architect(s), a business analyst and a project manager. The work is accomplished through a series of sessions where the team writes code, then tests working modules of the system and repeats the process. There is minimal documentation as the team relies almost exclusively on informal internal communication.

Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced. The Agile team identifies and prioritises the features based on business value, and after high-risk components of the system are produced, works on the highest value features first. This approach works if the solution can be delivered incrementally to the customer. If this is not possible, features still can be built incrementally and then integrated into the first release of the system.

Agile Management Components

There are several key elements that provide the basis for APM. These techniques can also be used in traditional software development methods to improve project performance.

They are:

Visual control. This is a "cards-on-the-wall" method of planning to assist a team in organising the work of the project. For example, one successful Agile project team placed different colour groups of cards that represented the features of the solution on the wall. The features that were designed, developed, tested and in production were one colour, the features that were designed, built, tested but not yet put in production (but ready to go) were another colour. The team was able to see at a glance where they were with each feature set. Visual control ensures that every member of the team views the project the same way.
Co-located high-performing teams. In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of co-ordination and communication. However, this may represent a significant cultural change for IT developers. Since project managers are responsible for building a high performing team, they need to ensure that they have been assigned developers who truly can work in this collaborative manner.
Test-driven development. In cases when the customer is having a difficult time articulating requirements, Agile teams often use test-driven development. This requires more iteration between requirements, design, development and test. Agile teams almost always develop test plans at the same time they define requirements; if a requirement isn't testable, then it is not yet fully developed. This is a best practice that can be used in traditional development to ensure requirements are complete, accurate and testable.
Adaptive control. Everyone on the team is constantly adapting. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster. Instead of setting rigid instructions for the team to follow, the project manager facilitates the team in establishing working relationships, setting ground rules and fostering collaboration. Agile team members continuously adapt to improve their methods as they incorporate lessons learned from the previous cycle into the next iteration, also a best practice for any project.
Collaborative development. APM relies on collaboration among all team members to deliver results, capture candid feedback and implement learnings on the next iteration of the solution. This is one of the strengths of APM constant feedback and improvement. The project manager completes the initial planning and the business analyst defines and prioritises the solution features in collaboration with the customer and technology representatives. Then the Agile project teams collaborate on the design, development, testing and reworking of each incremental build. It is this constant collaboration with the customer that promotes project success.
Feature-driven development. This practice greatly reduces complexity and allows the team to focus on one feature at a time. For example, one team is working on Feature #4 and that's the team's only focus. They don't concern themselves about Features #1-3. It is the business analyst and project manager who ensure the next feature in the backlog is truly the next priority, based on business value and risk. Typically, high-risk components or core infrastructure pieces are built first, and then everything else is prioritised based on business value. The goal is to build the feature-driven components with only a one-way dependency to the core system; therefore, specialised components are independent of each other and can be created in any order or even in parallel.
Leadership and collaboration rather than command and control. "The principles of APM are timeless and links closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management," says Sanjiv Augustine, Managing Director of the Lean-Agile Consulting Practice at CC Pace Systems in Fairfax, VA. The project manager works with the client management, the IT management and the key stakeholders to ensure they know the project's status. Additionally, the project manager removes any barriers hindering the core Agile teams.
Move focus from C (cost) to R (revenue). Features are prioritised based on value, such as increased revenue or market share. It's the business analyst's role to ensure the Agile project team is not investing too much into the development of the new solution. If so they will have eroded the business case and the project will cost more than the organisation will gain. While the project manager focuses on project costs, the business analyst focuses on the total cost of ownership that includes not only the development or acquisition costs of the new solution, but also the cost of operating the system after it is deployed.
Lessons learned. After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance.

The Value Proposition

"The traditional project management approach," Augustine reports, "is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once up-front and then deliver it in what's known as the Big Bang. That industrial age thinking has spilled over from software development to other projects as well." This is the heart of the difference between Agile and traditional project management.

The Big Bang now comes from the greater flexibility and collaboration APM provides. "Just enough" planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback. Since the customer sees and/or experiences a working prototype, he or she is better able to refine or redefine requirements and describe to the team what the organisation really needs. The Agile method embraces changes that add value, and reduces the cost of change through iterative development. Making changes to a small module is very cost-effective, compared to designing and developing a huge system and then trying to make changes to it.

Can Agile Project Management Work?

"At its heart, project management, traditional or Agile, has very similar principles. It's about doing a good job for the customer. It's about leading a team. It's about delivering measurable business results," says Augustine. Many of these principles or practices can be implemented into most team-structured environments. Yet, some project management professionals may discard the principles of Agile management if they are unable to adopt all of the components and practices. This is a mistake. For example, what happens if they cannot get the user to sit full-time with the team in the workroom? It doesn't mean they can't incorporate some of the other pieces of Agile management such as visual control and feature-driven development. Besides, even if a user cannot be involved on a full-time basis, most users are willing to participate on the team, especially during the testing and feature prioritisation. The rest of the time, the business analyst can represent the user while the fulltime core team continues to work together.

Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organisation. It's important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs. In this way, the benefits of the project will be obvious, whether the team is constructing a building or developing a new business solution.

3 P's

2008-12-17T03:33:00.000-08:00

By Laurence West

This is an article about Presentation, Planning and Processing; the three cornerstones of project management.

Anyone who has ever tried to organise something important seems to either love it or loath it. I remember friends organising trips out for people's birthdays and just not being able to cope with having multiple people to deal with, the planning of train times or car pools and the often continual flood of questions, niggles and other bits and bobs that are important to the person, but overall not so key.

Therefore I would like to break project management down into three categories and speak a little about each and what it means for our clients. All three categories are equally important because with one omitted your project will be earmarked for failure from the start and it is likely only a matter of time.

Presentation

This is not presentation in terms of securing the business, it is more about the presentation of the project on an ongoing basis. The project manager is the one who knows about all the different aspects of the project and is normally the one people come to with questions. Therefore it is your general method and approach to different departments and to the project as a whole that is important.

It can be hard to find the right balance between urgency and taking a relaxed attitude to things and it has to be modified and rebalanced for almost every project. However, a general rule of thumb is that if it's important it's urgent unless otherwise stated.

A second rule of thumb is even if something is urgent, appear somewhat relaxed about it. There is nothing better to instil calm confidence in someone than the project manager running round in circles crying "It's all over! It's all over!"

Presentation is also important to keep people focused on the project. Often people and clients come to a project with all guns blazing and more promises than a labour government, but as soon as other projects call there is too great a split in their time causing at least one project to suffer. This can be painful to watch as you know that every day that goes by is a day where they could have been making more money than before.

Therefore it is important to keep all people intimately involved in the project so that they stay focused and continue to understand its importance months after the start date. The freshness of anything new is often exciting, but it is important to keep that going throughout the whole time frame of the project.

Processing

This is processing in almost a mechanistic way where following procedures to the T is important. It is critical that the project manger is on the ball with the project as a whole and if they can't work through each step then it is unlikely anyone else will be able to.

This links in with being calm and processing information and problems in a logical fashion. It is rare that something goes so drastically wrong so quickly that the project is over however, it may seem like that at the time. Perspective on events is important and this can come from processing information in such a way that you end up with the correct answers to that frame of reference and can work from a stable foundation.

Ending up with the right answers is not a matter of bending things so they fit your client's goals and objectives, it is about using a tried and tested method to arrive at a conclusion. If things aren't looking great then work smarter so they are better next time. As Ed Boyden says "make your mistakes quickly" and move on.

With all aspects of project management it is important to make sure that you are precise, particularly in terms of your goals and expectations. Managing expectations and keeping them focused, grounded and in check is incredibly important to overall success. Personally I always have two or three sets of goals: minimums, expectations and ideals so I can gauge how well something is doing in terms of its proximity to failure and sky rocketing.

Finally, the two coldest aspects of project management processing are analysis and the setting of priorities. Here you must set all personal feelings aside, put one thing before another and crunch some numbers. Sometimes things just don't make the cut and part of good management is being able to cull those aspects.

Planning

Need I say more? Plan, plan, plan, plan and plan some more! Plan to succeed, plan to fail and plan for everything in between. This is the most important aspect of project management. I want to say it doesn't matter how to plan, but often it does. Make your planning clear, effective and for god's sake make sure it covers all the bases!

Ultimately you want to plan to be:

On time, more commonly know as early. Just because others are late it doesn't mean the project has to be (particularly if you planned for them to be late!).
On budget, plan for the extra expenditure via experience from similar situations.
On track for producing a high quality product by planning all aspects and eventualities whilst managing expectations and objectives.

Conclusion

Project management is an immense field and one which changes from industry to industry and project to project. Rarely will two be the same and personally I find it worrying if it goes 100% smoothly for too long. Planning is fundamental but it cannot dominate the landscape; processing and presentation have their own amazing benefits and taking advantage of them is only the start of a great project!

Agile and Waterfall

2008-12-17T03:31:00.001-08:00

By Gina Lijoi

While there are likely as many unique Project Management approaches as there are Project Managers, there are two well-know production cycle methodologies that have been the topic of much discussion in PM circles - agile and waterfall methodologies. As I evolve in my own area of expertise, I am constantly reinventing small aspects of what I consider best practice. Most recently, to address the incredibly complex requirements of a large client initative, I challenged myself to come up with a "super" Project Management process that would not only improve the way in which we deliver, but what we deliver at the end of the engagement. I determined there was a way to combine the best features of waterfall development disciplines with agile principles for superior results.

Simplistically, the waterfall approach infers structure, control, progression and finite project cycles. This approach works when you have access to limited resources and when specific hours are assigned to granular stages of a project phase. Agile is different in that additional leaway is given for teams to iterate through a single deliverable numerous times until a level of satisfaction is achieved. It's difficult to implement this approach when you are working with shared resources, or when time to market and budget cannot be shifted. It's important to understand my descriptions of the two approaches are extremely simplified and highlight key differences - for this article, it's important that I make the distinction clear. I encourage all readers to conduct their own research into each approach more thoroughly.

Both approaches boast significant and different benefits, and are generally seen as being mutually exclusive of one another. It can be argued, however, that certain elements of both paths can be merged into a single process to achieve greater results. With this in mind, I have proposed a slightly refined process to my internal team, where iterations can be accommodated, but are scheduled within a defined process and period of time. In order to deliver on this approach, the efforts of multiple departmental leads (such as Information Design, Interface Design and Technical Development) must ocur concurrently so that the team can produce deliverables as a single entity. By doing this, each person's feedback is representative of the iterations which normally ocur as a deliverable is transitioned from department to department. The net result is a more controled cycle where iterations can still be accommodated.

I believe that the quality of an end deliverable will be superior when the expertise of each lead can be amalgamated into a single output. This style of collaboration will also result in a greater understanding of practice areas among the larger team - this will create long-term synergies that spur individuals to consider varying points of view, even when they work isolation.

This approach may seem like a very small deviation from standard operating procedure, but asking different subject matter experts to come together and produce one element together represents a big shift in previous thinking. This approach moves traditional agencies away from a manufacturing-based production cycle, and propels them forward into a more advanced collective and collaborative environment. As online initiatives take on more sophistication in usability, interface design and technical functionality, there will be a stronger mandate for this style of production.

Execute...Or Be Executed

2008-12-17T03:30:00.001-08:00

By Lonnie Pacelli

Avoid a trip to the project management guillotine by keeping some of these simple tips in mind.

Talk about your character-building experience...

I was a young hot-shot project manager on an engagement that I had sold to a client. I had it all planned out and had delusions of completely delighting my client with an issue-free project. It all seemed so simple, then the project started and never finished.

I'll spare you the gory details of my harrowing experience, but what I can tell you is that I put more focus on selling and planning the project than I did on its execution. I took a naive attitude of the project being able to pretty much run itself with some junior analysts running the day-to-day aspects of the work. It blew up in my face and I got booted from the client never to return again. It was my inaugural visit to the project management guillotine.

Any project manager who has been around the block a few times has experienced a visit to the project management guillotine. Perhaps it was with a sponsor, management, or a customer. The project either had a massive schedule slip, cost overrun, or scope slash (or sometimes all three - now that's a party!) and the project manager was first in line at the guillotine. Some of my most uncomfortable situations in my 20+ years as a professional have involved me getting my head handed to me on a silver platter because I bungled a project.

Visiting the guillotine was very uncomfortable but at the same time was a great learning experience. It taught me that I not only needed to be good at planning a project, I also needed to excel in its delivery. It wasn't enough to be only peripherally involved in a project or to be its administrator. I had to know what was happening, be on the lookout for problems, and squash the problems before they had a chance to spin out of control. It taught me that I needed to avoid the guillotine by being able to execute. It was that simple: Execute or be executed.

Avoid a trip to the project management guillotine by keeping some of these simple tips in mind:

Break large projects down into mini projects that are three months in duration: I've rarely seen a project manager who is running a long-duration project raise a schedule issue early on in the project. Most times, schedule issues get raised during the last third of the project. Is that because the last third of the project is usually the most complex in nature? Hardly. It typically means that the project manager either wasn't aware of earlier problems or just slipped tasks without raising any alarm bells that the overall project was slipping. Break larger projects down to short-duration three month mini projects, which have a clearly defined deliverable associated with the project's completion. Running mini projects not only keeps everyone on their toes with the completion date just around the corner but can be an fantastic motivator for project team members to git-er-done.
Communicate the facts regularly: Regardless of whether the news is good or bad, the project manager absolutely has to establish and maintain a steady rhythm of communication about how the project is going. I personally like doing a pointed weekly status which focuses on cost, schedule, risks and issues. If there is good news to share, do it. If there is bad news to share, do it and tell what you're doing about it. Don't suppress communication waiting for a "Hail Mary" to save the project. It likely won't happen.
Avoid "whine and cheese parties" when raising issues: Yes, issues are going to happen, and yes, some of them can cause your project to fail. This isn't the time to show panic or to get on your soap box about how tough the project is. As the project manager, your job is to raise the big issues, articulate what needs to happen to resolve the issues, put a name next to each issue for resolution, then hold those people accountable for resolution. Keep a cool head and stay focused on resolution, don't use the platform as a means to say "I told you so."
Maximise the value of your trips back to the well: So okay, sometimes you can't keep it all together without revising either cost, schedule or scope. When faced with the situation of having to go back to the sponsor (or the person writing the cheques) I've found a couple of things to be very helpful:
- Give the sponsor alternatives which allow him or her to choose between relaxing scope, schedule, and/or cost. Too many times I've seen project managers pre-assume what needs to happen and not present alternatives to the sponsor. Allow the sponsor to be part of the decision making process.
- Minimise the number of times you have to go back to the well. It is very frustrating for a sponsor to agree to a scope/schedule/cost variance in one month, only to have the project manager come back the next month looking for an additional variance. Understand the implications of the variance and present reality to your sponsor.
Ask for help, don't abdicate responsibility or tough it out yourself: I learned this lesson very early on in my project management career. As a young buck I saw it as a sign of weakness to ask someone for help if I got in trouble. Asking for help meant I wasn't cut out for the job and management would view me as incompetent. Through the years I've refined my attitude about asking for help pretty significantly. It's not about raising the flag any time the smallest issue crops up; it's about knowing what issues are within my domain to fix and knowing what issues can best be addressed by someone else. There's not a good reason to try to tough it out yourself; ask for help when you're in trouble. On the other end of the spectrum is the project manager who leaves the helm. Rather than trying to fix a project problem, I've seen the project manager run for the exits or try to get assigned on another project to get out from under the mess. As the project manager you can't run for the exits; you've got to stay with the ship and work through the tough problems. Just don't swing the pendulum too far the other way and forget to ask for help.

Writing an Unbeatable Business Case

2008-12-17T03:26:00.000-08:00

By Simon Buehring

A project brief describes what needs to be done. The project plan explains how you are going to do it. The business case gives the reasons why.

In PRINCE2 terminology, the business case is the "driver" of the project. Senior management review the business case before authorising the initiation, and at each subsequent stage of the project. The business case is used as a yardstick to measure project progress. Before allowing any change to the project plan, the executive must consider the impact that this change will have on the business case.

In other words, without a business case, no project would ever get off the ground.

The business case justifies the investment of time, money and resources into a project by outlining the benefits that the project will bring. It is made up of eight key sections:

Reasons

Why is the project necessary?

The reasons you give must conform to corporate/programme strategy. You'd have a hard job convincing a clothing manufacturer that an advertising campaign persuading people to recycle last year's clothes instead of buying new ones would be an appropriate project to undertake. Another way of thinking about the reasons for a project is to consider what need the project will address. Is customer satisfaction low? Do your profit margins need a boost? Are you still using the same, snail-paced computers you acquired in 1983?

Options

What different options are available for addressing the identified need? Why is the option you have chosen (the project) the best of the bunch?

Showing that you have seriously considered all the possibilities will strengthen your business case. Providing senior management with all the available information will also maximise the chances for somebody to suggest an improvement. It is much better to change your project plan now than to watch it all collapse halfway through.

Benefits

This is where you persuade your audience that your project is worthwhile. Every possible benefit can be considered, tangible and intangible. Just make sure that you justify the benefits that you project.

If your project will increase profit, then present detailed figures as evidence. If the primary benefit is improved customer care or staff efficiency, then explain how this will happen and what the effects will be.

Risks

What are the main risks to project success? Be frank. Transparency will gain the confidence of senior managers and will demonstrate your foresight, realism and capability.

Cost

The senior project managers need to know the total projected cost before they can authorise the project. Justify each area of expenditure, so that nobody is in any doubt that the budget you have forecast is as accurate as possible.

Timescale

How long will the project take? Detail the activities and goals of each stage, and explain why the specified length of time is needed.

Investment Appraisal

This is where you pit the cost and beneits against one another in order to demonstrate once and for all that your project is a worthwhile investment. Before senior management can authorise your project, they need to know what they are getting for their money.

The investment appraisal, by detailing the costs and benefits over a fixed period of time, is the most direct way of quantifying "value for money."

Evaluation

Consider your own business case in an objective light. What are the strongest and surest benefits that you have promised? Why are they necessary? Why is your project the best way of achieving them?

Communications Management

2008-12-17T03:16:00.000-08:00

A communication plan like the project plan is a necessary part of a project. It's been said that communication is the lifeblood of projects.

Project Communications: How to Keep Your Team Engaged and Informed

Good communication is vital to the success of your project. This article explores the methods used by successful project managers to tailor their communications to suit their audiences. It offers advice and tips on how to implement the best practices taught by the PMBOK and many PMP Exam Preparation courses.

Effective Project Communications

As a Project Manager, communication will occur in many forms, with many individuals, including project stakeholders, your internal team, management within your organisation, vendors, and more. Communication may happen verbally or through e-mail, as well as through charters and project plans, addendums and status reports. These long lists are a small indication of the significance of communication to a Project Manager.

Project Management of a Global Team

The world is getting smaller. Well, it isn't physically getting smaller but that is one way of saying that global communications have become so fast paced that the world is really one community in a lot of ways. With the advent of the Internet, email, instant messaging and VOIP, it is entirely possible to have your project team members around the globe.

Project Management Starts with a Capital "C"

Communication, Communication, Communication! In our world of project management today, it has become increasingly more important to turn our efforts toward more effective means of communication, especially since many of us are faced with more and more virtual teams operating around the globe. Start your projects on the right foot, with a "Capital C" and begin the communication process early and often!

Real World Project Management: Communications

Communication is more than just talking. Communication is also listening. When it comes to project management, communication takes up 90% of a project manager's time. That's right, 90% of your time.

What is the Secret to Project Management?

As the director of the project management discipline for a leading Interactive Agency, I interview quite a few people. A standard question I ask during a typical first interview is "What do you feel is the secret to project management, in other words, what separates good project managers from great project managers?" It is a pretty open-ended question and there is no right answer, but it is a great question to gain greater insight into the depth of the candidate. The most common answer I get is "communication, making sure everyone knows what is going on." While this is not incorrect, I think there is a much deeper and truth-seeking answer beyond this stock response.

Obstacles to Project Communication

Communication is so important to project success that it has been referred to as the lifeblood of a project by more than one practitioner. Jack Vinson talks about the importance of communication across project interfaces - interfaces being boundaries between different groups within an extended project team. He views interfaces as constraints that limit project success. On reflection, I realised that many project communication issues I've encountered have, in fact, occurred at interfaces. In this post I explore the notion of an interface as an obstacle to project communication.

Communication: The Lifeblood of a Project

The communication plan like the project plan is a necessary part of the project. However, when thinking of the project manager's role in communication planning look beyond the written word and the outline prepared in the early phases of a project, otherwise you are setting yourself up for project losses.

Change Management

2008-12-17T03:15:00.001-08:00

Change management is the practice of tracking and administering changes during the development of a product or service and is a key part of project management.

Strategies for Managing Change: The Project Manager

The title of project manager (PM) is used to mean different things in different companies. Fortunately there is a standards body called the Project Management Institute which provides excellent guidance around the role and function of a project manager. Some will disagree, but I don't care if your project manager is PMI certified or not. You need to care about having a project manager with the skill to carry out the role as the Institute defines it. It's your change management strategy, and it's your reputation on the line.

Understanding Change in a Quality Culture

Managing Change Successfully: Six Layers of Resistance

Making Change Happen

Push-Me Pull-You Projects

Change Management in Practice: Why Does Change Fail?

What is Change Management?

The change management process is key to the successful outcome of a project. The process ensures that each change introduced is properly defined, considered and approved before implementation.

Persuasion and Perception

Top Tips for Project Implementation

2008-12-17T03:14:00.003-08:00

By Neil Davidson

"Coming together is a beginning. Keeping together is progress. Working together is success." This quote from Henry Ford was used by a proud dad at a recent wedding I attended. It was a well chosen piece of advice, but as the managing director of a business solutions provider the quote hit a familiar note with me because it sums up exactly what we have been telling our clients during the implementation process.

In an increasingly fast paced world, clients want implementation to be quicker and less intrusive. It's a tough thing to achieve because implementing a business solution is not a straightforward process, and there are certainly no quick fixes.

Completing a project quickly may please the client in the short-term but in the long term there's a high chance that everyone loses out, there are many examples of projects which have ended in acrimony and disappointment.

There needs to be a good relationship between whoever is delivering the project and the client in order to make it a success, but as Ford says, both parties need to work at it. It's understandable that companies want things done quickly, in theory it keeps costs down and doesn't disrupt the core business. But rushing things inevitably leads to mistakes.

At Maconomy, we provide project management and planning systems, so it's vital for us that our implementation plan is effective and successful, it's our bread and butter. But in order for this to work properly, the management team need to appreciate that in order to make an omelette, you need to break a few eggs.

So what steps can organisations take to ensure implementation projects run smoothly and end in success for all those concerned?

Sell in the Idea Internally

The management team in any business sets the tone and expectations for the rest of the employees. Therefore, it's important to get the team behind the project and driving it forward right from the beginning. This will enable the whole business to understand the benefits of the new system, and how their current business processes will change for the better. Scheduling company or team meetings, regular e-mail newsletters and bulletins are all ways of transferring this message.

Engaging employees early is therefore very important. Assessing the firm's current processes is a good way of doing this, and it also enables you to understand how the new business solution can be tailored to work within the business. Find out how people plan, what methods and programmes they use, and how they control costs and deadlines. These types of questions give valuable insight into the way the business currently works and gives those people involved the opportunity to provide input.

The next step is to understand how the existing business processes can be improved. In order to ensure that a new system is utilised to its full potential it needs to be aligned to the goals of those using it.

Seek and Ye Shall Find

There are a multitude of different solutions out there and it's important that you find the right one for your business needs. The solution that you choose should be able to work as a stand-alone product, or integrated into any existing IT system. Business processes differ from company to company, so the solution needs to be flexible and above all, user friendly. After all, it is likely that people will be using it on a daily basis.

Change is as Good as a Rest

Change management is possibly the most important factor in the implementation process. When a company is adopting a new ERP or finance system there are huge changes to their business processes, so there is a definite learning curve. Ideally, change management should be led by a consultant and it's important that at the start of implementation the consultant is ready with a change management blueprint tailored for the business.

Fundamental to the successful running of the blueprint is communication. Both consultant and client need to clarify how they will communicate the changes to the employees, be it department-specific or company wide meetings, intranet or newsletter releases, training days or WebEx. However you decide to do it you have to focus on two factors: always reiterate the business benefits of the implementation, and don't underestimate the support and ongoing training that your employees will require.

A very effective change management technique is to adopt a guinea pig department to pilot the new approach. Rather than a big-bang start, it is much more productive to begin with one department, this requires one department to test drive the system. This allows the consultant and the client to monitor the system at work on a small scale and react to any resulting issues. This steady progression generates confidence and understanding.

This gradual process of integration should be replicated with individuals as well. They should be encouraged to start off slowly and build up their knowledge and confidence of the new system. Being thrown in at the deep end can be daunting so it's important that everyone is comfortable, it may seem like hand holding, and those looking for a quick implementation may see this as unnecessary, but it's time well spent.

Use it Successfully

Once the implementation process is completed there needs to be a period of monitoring and assessment of the functionality, how is it working and who is using it well, who is experiencing teething problems? This needs to be done so that the investment is not wasted and the system is thoroughly effective.

We have found that approaching implementation in this way is a very successful strategy. It's about linking the soft skills, like team work, communication and knowledge transfer with the logical and practical skills that are also required to make any implementation work. No implementation is worry-free, but with a good provider, a great consultant and with this advice in mind, the process will be straight forward, predictable and manageable.

Managing Project Management

2008-12-17T00:52:00.000-08:00

By Joseph Phillips

Oooh - project management. Everyone talks about project management but what is it? Isn't project management just organising your little work to get the big work done? Isn't project management really just a series of events to create some thing, by some point, way off in some hazy future? Not really.

To define what project management is we first need to define what projects are. A project, technically, is a short-term endeavour to create a unique product or service. A project, in practical terms, is an assignment or undertaking to create a deliverable that satisfies the mission of the project customers.

A project is a set of activities to create something that is outside of your day-to-day operations. A project creates a unique deliverable. For example, if your organisation develops game software the actual creation and development of the code is a project. The manufacturing of the CDs, the Internet delivery, and the technical support you provide to your customers is part of maintenance and operations.

The difference is that one set of activities creates a unique deliverable while the other centres on organisational process, day-to-day business, and support of the organisation's mission. This is true in disciplines other than IT: consider designing a car versus manufacturing a car. Consider writing a book versus printing a book. Consider building a skyscraper versus maintaining a skyscraper.

Projects have budgets, deadlines, and an agreed set of requirements for the deliverable to be accepted by the customer.

The United States of Project Management

In my project management seminars I like to say that this point in the room represent our current state; this is where our organisation is today. We have some opportunity that we'd like to seize. We have some problem that we'd like to solve. Or there's technology that has leapfrogged our current equipment so we need to improve our technical attributes. Where we are now is our current state.

Then I'll stroll to a distant part of the room. This new location represents where we want our organisation to get to. This describes our desired future state. Can you imagine how great our organisation would be once we reach this destination? Can you imagination the problem solved, the seized opportunity, or the new technology and how it makes our business better? This spot represent our desired future state.

The only way we can get from right here, our current state, to our desired future state, which is way over there, is through project management. Project management is about planning, doing, and ensuring that we've followed our plan. Here's a key thought: the only way we can do project management, effective project management, is to know where our desired future state exists.

Effective project management is built on a solid foundation of planning. Then the project team must execute the work according to plan. And the project manager must control the work to ensure that the project plan was followed. Plan. Do. Check. React. Project management, quite simply, is knowing where we're going, planning on how we'll get there, and then delivering on the promises within the plan.

Projects, all projects, have constraints. Have you every inherited a project that had to be done by a given deadline? Remember the Y2K scare that turned out to be the Y2-OK yawn a few years ago? It was real tough to move that deadline. January 1, 2000 was coming ready or not.

Or have you ever managed a project that had a preset budget? Regardless of how long it took your project could not, must not, spend more than $750,000. Or else. A pre-set budget may be calculated on how much cash is in the bank account, the expected return on the project investment, or some other magic formula like the time value of money. The point is, a pre-set budget is constraint.

Finally, you may have faced a project that had some very steep requirements. Are you a public company? Then you've dealt with the Sarbane-Oxley Act. Or if you're in health care you've dealt with HIPAA. Or the regulations you may have to follow in pharmaceutical, construction, manufacturing, and countless other industries.

You may also have worked with a customer that said, "I don't care how much it costs or how long it takes. I need the product to do this." (Those are my favourite kinds of customers, by the way.) These steep requirements are part of the project scope and in order for the project to be successful the project scope has to be met.

You've just read about the triple constraints of project management: time, cost, and scope. The triple constraints of project management are collectively called "The Iron Triangle." Imagine an equilateral triangle. The bottom of the triangle represents scope, another side represents cost, and the last side represents time.

In order for the project to be successful the project must remain an equilateral triangle. In other words, you can have a gigantic scope, and puny budget, or a weak schedule. For a project to be successful each side of the Iron Triangle must remain in proportion to the other sides. If your customer wants a scope that's so big (hold your arms out real wide). And their budget is only this big (now bring your arms in real close together). A big ol' scope and tiny little budget means just one thing: it ain't gonna happen.

The same is true with the schedule. There must be enough time to plan and execute the project in order to achieve the project's scope. Unrealistic expectations on the schedule usually leads to waste, rework, frustrations, and a decline in morale. In some instances this may also lead to cheap tequila.

Capturing The Picture

I like photography. I like to look at pictures, take pictures, and mess with filters, lenses, and light metres. In order to really capture a good photo, I've learned, you have to see the developed photo in your mind's eye. You have to look at your environment and see how it'd look once the film's been developed or the image is printed on your colour laser printer. You have to see into the future in order to capture the present in your camera. You must have vision. Being a project manager really isn't that different. A project manager must have vision for what the project is to create. The project manager inherits the vision from the key stakeholders, the project sponsor, or even management. In order to plan for the project work the project manager must envision what the end result of the project will be. Like taking a photo, a good photo, the project manager has to study, observe, and see the end result of the efforts before the work begins.

Another way to look at your new friend the Iron Triangle is to imagine the photographer's tripod. If you've ever worked with a tripod (hopefully with a camera on top) you know the secret is to have the tripod balanced and level. In fact, some camera tripods have a level built into the head so you know when it is level. A level tripod ensures that the photo's horizon is flat; it makes a goofy picture when the ocean is slipping down to South America.

Now imagine that one leg of the tripod equates to scope, another to time, and the last is cost. We agree that the tripod has to be balanced to take a good picture, just like a project has to have balance to be successful. If any leg of the tripod is extended more than the others the tripod is off-balance - just like your projects.

Some tripods are nice and heavy. A heavy tripod helps when you've taking a photo in the middle of a river or you're fighting a wind storm. The trouble with heavy tripods is someone has to carry them. What some photographers do is carry a light tripod and then suspend their camera bag under the tripod to fend off any shakes. A neat trick.

In project management what's keeping your project sturdy? Imagine that the area within the three legs of the tripod represents quality. If any leg of the tripod is out of balance then quality is likely to suffer. Quality is in proportion to the amount of time, cost, and scope available for the project deliverables. When one angle of the project suffers so does quality.

What good is a project's deliverable if the project is finished on time, but the product or service doesn't work as promised? Or if the project manager has spent all of the money but didn't create all the promised deliverables? Quality is affected by the balance of time, cost, and scope.

Following this snappy analogy of photography, what kind of camera would you like to put on top of your tripod? If you're like me, I bet you'd like a digital SLR, capable of 12 megapixels, and a few gigs of memory for your digital photos. Of you could rely on a manual 35mm camera, with slide film, and a nice set of filters.

But wouldn't you have better photos with the 12 megapixel digital camera? Not necessarily. Just because you have a fantastic camera doesn't mean your photos will be fantastic. It's not the camera that takes the pictures - it's the photographer.

The camera, in our project management analogy, are the mechanics of project management. The person behind the camera is the project manager. Just as the photographer has to know how to adjust the camera to capture the perfect photo, so does the project manager adjust the controls within project management to deliver on the project's demands.

Good photographers and good project managers have much in common: experience, a foundation in the fundamentals, and a willingness to learn. At the core, I believe, is an ability to capture a vision - and then process that vision for others to see.

Projects Tell a Story

If you don't like photography maybe you'll like stories. Projects, like a good story, have a beginning, a middle, and a satisfying end. Think back to any project you've managed or worked on. Can you recall the beginning, middle, and a Hollywood ending?

The story for all projects is that they move through five process groups to get from start to finish. Within each process group there are key activities which help a project move along.

Initiate a Project

This process group starts all the fun. In this group the business need for the project is identified, some initial solutions may be proposed, and the project manager is selected.

The most important document to come out of this group is the project charter. The project charter authorises the project work and assigns the project manager the power to complete the project on behalf of the project sponsor. The project sponsor is typically someone high enough in the organisational hierarchy to have power over the resources that need to be involved in the project. (Having a weak sponsor for your project can also, unfortunately, lead to cheap tequila.)

Planning the Project

In order to plan the project manager must know what the project will create. The project manager and the project stakeholders - the people that have a stake in the project outcome - have to determine what the desired future state is. A dreamy wish list won't work. The project demands exact requirements. If you don't know what the project should create how will you ever get there?

Once the project requirements have been agreed upon then the project manager, the project team, and in some instances the project stakeholders will create a plan on how to achieve the project objectives. This isn't a one-time process. Planning is an iterative process that happens throughout the project duration. Planning is a cornerstone of project management - skip planning or do it half-heartedly and the project is doomed.

Executing the Project

Ever hear the quip, "Plan your work and then work your plan?" This is the working part. The executing process group is the project team executing the project work according to plan - and the project manager working with any vendors that may be involved in the execution or support of the deliverables needed for the project completion.

Controlling the Project

Control freaks need not apply. Controlling isn't about micromanaging - it's about compliance with the project plan. There's balance between execution and control. The project manager works with the project team, not over them, to ensure that they're doing the work as it was planned. And if not? Then the project manager makes corrective actions to get the project back in alignment with the project plan.

Controlling is also about balancing the time, cost, and scope constraints as the project moves along. The project manager has to measure, compare, and adjust controls within the project to ensure project success. If we do not measure we cannot improve.

Closing the Project

Aaah - closing. This process group centres on closing out the project accounts, completing final, formal acceptance of the project deliverables, finalising any time, cost, or quality reports, completing the project's lessons learned documentation, and finalising any financial or procurement audits. The project manager may have to complete a review of each team member, a review of the vendors, and a review of their own actions in the project.

Project closure also involves some rewards and recognition. For some, this means bonuses, vacation time, or other rewards. If this isn't appropriate or available in your organisation the project manager should at least verbally reward the project team for their hard work and a job well-done (assuming the project was done well).

Putting it all Together

As you know projects are short-term endeavours to create a unique product or service. Projects are out of the normal duties you do as part of your operations. Projects are constrained by time, cost, and scope - and other constraints such as regulations, resources, or even vendors.

The Iron Triangle of project management posits that all projects are constrained by time, cost, and scope. If one angle of the project is out whack the whole project suffers.

Projects, and technically even project phases, move through five process groups: initiating, planning, executing, controlling, and closing. Each process group has key activities that lend to a successful project. I believe the most important group is planning. Without planning the project is destined for failure.

What we've discussed in this intro to project management is a good foundation for how projects are to operate, their constraints, and a some challenges every project manager faces. On top of this strong foundation there are nine knowledge areas which also affect a project's success:

Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resources Management
Communications Management
Project Risk Management
Project Procurement Management
Project Integration Management

For each of these knowledge areas I've written an article which explains their characteristics and how they contribute to your projects.

For now know this: projects are successful based on the ability of the project manager to lead, manage, and motivate the project team to complete the project plan. The project plan supports the vision the project manager has inherited from the project stakeholders. If the project manager and the project stakeholder don't have the same vision of the desired future state the project is doomed.

Projects fail at the beginning, not the end.

Brife

2008-12-17T00:46:00.000-08:00

Introduction

The purpose of this paper is to gain an understanding of project management and to give a brief overview of the methodology that underpins most formally run projects. Many organisations do not employ full time Project Managers and it is common to pull together a project team to address a specific need. While most people are not formally skilled in project methodology, taking a role in a project team can be an excellent learning opportunity and can enhance a person's career profile.
What is a Project?

A project is a temporary and one-time exercise which varies in duration. It is undertaken to address a specific need in an organisation, which may be to create a product or service or to change a business process. This is in direct contrast to how an organisation generally works on a permanent basis to produce their goods or services. For example the work of an organisation may be to manufacture trucks on a continual basis, therefore the work is considered functional as the organisation creates the same products or services over-and-over again and people hold their roles on a semi permanent basis.
What is Project Management?

A project is generally initiated by a perceived need in an organisation. Being a one off undertaking, it will have a start and an end, constraints of budgets, time and resources and involves a purpose built team. Project teams are made up of many different team members, for example, end users/customers (of a product or service), representatives from Information Technology (IT), a project leader, business analysts, trainers, the project sponsor and other stakeholders.

Project management is the discipline of managing all the different resources and aspects of the project in such a way that the resources will deliver all the output that is required to complete the project within the defined scope, time, and cost constraints. These are agreed upon in the project initiation stage and by the time the project begins all stakeholders and team members will have a clear understanding and acceptance of the process, methodology and expected outcomes. A good project manager utilises a formal process that can be audited and used as a blue print for the project, and this is achieved by employing a project management methodology.
Project Management Methodology

Generally, projects are split into three phases Initiation, Implementation and Closure. Each phase then has multiple checkpoints that must be met before the next phase begins. The degree to which a project is managed will depend on the size of the project. For a complex project in a large organisation that involves a number of people, resources, time and money, a more structured approach is needed, and there will be more steps built into each stage of the project to ensure that the project delivers the anticipated end result. For a simple project in a small organisation, agreed milestones, a few checklists and someone to co-ordinate the project may be all that is required.
Initiating a Project

All projects start with an idea for a product, service, new capability or other desired outcome. The idea is communicated to the project sponsors (the people who will fund the project) using what is called either a mandate or project charter. The mandate is a document structured in a way that lays out a clear method for proposing a project and should result in a business case for the project. Once the business case has been approved a more detailed document is prepared that explains the project and it is known as the 'The Project Definition Report' (PD). The PD is not only used to provide detailed information on the project, but is the report on which an assessment is made as to whether the project should proceed or not. Some of the key areas it covers is the scope of the project, results of any feasibility studies, and what it is intended to deliver. As well this document will identify the key people involved, resources required, costs and expected duration as well as benefits to the business. A project usually has a goal (the big picture) and this has to then be broken down into objectives you can use to measure whether you have achieved your aims.

From this list you must then identify what is known as 'Key Success Criteria', and these are the objectives that are 'key' to the success or failure of the project - even if other objectives are met. These obviously vary from project to project. Once the project has been given the go ahead, then a contract document is drawn up and the project sponsor uses this to give formal agreement to funding the project and for the project to begin. The initiation phase is then considered to be completed.
Implementing a Project

The implementation phase is about tracking and managing the project. The first thing that happens when the project begins is to use the Project Definition Report to create a project plan which defines how to perform what is detailed on the PD report. The PD is more of a summary of the project, so a detailed project plan must be created to fill in the fine detail of how the project will be run. The project plan is the central document that is used to manage the project for its duration so getting agreement and acceptance from all of the team on aspects such as the project milestones, phases and tasks, as well as who is responsible for each task, associated timelines and what deadlines are to be met.

Some of the stages in implementing a project are quality control, progress control, change control and risk management. The first aspect we will discuss is risk management, as once you have planned the project it is important to assess any factors that could have an impact upon it. 'Risk' in this case is considered to be anything that could negatively impact on the project meeting completion deadlines. For example losing team members due to illness or attrition, not having taken team members' annual leave into consideration, the possibility of having to retrain new team members, equipment not being delivered on time or contractors going out of business. A risk log is used to record and grade risks and carries an associated action plan to minimise the identified risk. Issues management is an associated area and refers to concerns related to the project raised by any stakeholder. This phase also involves the Project Manager in quality control, whereby regular reviews are made in formalised meetings to ensure the 'product' that is being produced by the project is reviewed against specific pre-defined standards.

Progress Control is another responsibility of the Project Manager and is the monitoring of the project and the production of regular progress reports to communicate the progress of the project to all stakeholders of the project. As most projects do not go exactly to plan, the process of progress control is to keep an eye on the direction of the project and monitor the degree to which the plan is followed and take appropriate action if stages are deviating from the plan by employing regular project tracking. This is achieved by having regular checkpoints during the course of the project that will have been established in the project definition. These meetings may be weekly and are used to monitor and control all that is going on with the project as well as capture statistics from each project team member on actual start and finish dates for their allocated tasks as well as estimates for the next round of tasks.

By the nature of most projects never going exactly to plan, changes will need to be made to the length, direction and type of tasks carried out by the team. This has to be fully documented by the Project Manager in the form of 'change control'. Change control involves the Project Manager in documenting requests for change, identifying the impact on the project if the change is to be implemented (e.g. will it affect the finish time of the project, will the project run over budget, are there enough resources) and then informing all stakeholders of the implications and alternatives that the request for change has identified. The implementation phase ends once the project has achieved its goals and objectives as detailed by the key success criteria in the Project Definition Report.
Closing a Project

All projects are designed for a specific period of time and the process of project closure is an important aspect of project management. The purpose of a formal closedown to the project is to address all issues generated by the project, to release staff from the project and go through a 'lessons learnt' exercise. At this stage a formal acceptance from the customer (the person for whom the process product has been created) is gained to indicate their sign-off on the project. This is generally done in the form of a customer acceptance form and is the formal acknowledgement from the customer that the project has ended. Once signed off, the project team is disbanded and no more work carried out. However the project team will come together for what is called a Project Review Meeting, to formally end the project and go over any outstanding issues such as ongoing maintenance, the closing of project files and conduct a team review of the project. As a result a Project Closure Report is created to formalise how successfully the project has achieved its objectives, and how well the project has performed against its original business case, the scope, project plan, budget and allocated timeframes.

The Project Manager may also create a process improvement document that reviews the processes used by the project (e.g. what did we do well, what mistakes did we make) so that the organisation can learn from this project and make further projects more successful. Because the project was run by a team of people who have spent a lot of time involved in the success of a particular piece of work, that has taken them out of their usual day-to-day activities it is important to hold some type of social closing event. This might be a dinner, drinks or some type of group activity where everyone can be recognised and rewarded for their efforts.
What does it take to be a Good Project Manager?

Aside from understanding the methodology, there are other characteristics to keep in mind for successful project management. Given that any project is involved with a project team as well as the stakeholders, a good Project Manager needs to have not only excellent time management skills but also good people skills such as:

* Excellent communication skills
* The ability to be a team player
* Excellent interpersonal skills
* The ability to negotiate

Experienced Project Managers believe there are two key factors in determining the success of a project: 1. Recruitment and selection of suitably qualified project members to relevant project positions is essential. Recruiting of project team members should be handled with the same discipline and rigour as the recruitment of new employees to fulfil the ongoing positions in the business. 2. A well documented methodology that is kept simple and easily adaptable to different sizes of projects is a critical foundation for ensuring project success. This documented methodology needs to be communicated to project team members as part of the initiation stage. This will ensure such things as everyone having a clear understanding of how to progress and what is expected at each stage and that the methodology is adapted to the specific needs of the project being undertaken.

Definition n Intro

2008-12-17T00:02:00.000-08:00

Definition
Project management is a methodical approach to planning and guiding project processes from start to finish. According to the Project Management Institute, the processes are guided through five stages: initiation, planning, executing, controlling, and closing. Project management can be applied to almost any type of project and is widely used to control the complex processes of software development projects

Project Management

Project management in the modern sense began in the early 1960s, although it has its roots much further back in the latter years of the 19th century. The need for project management was driven by businesses that realised the benefits of organising work around projects and the critical need to communicate and co-ordinate work across departments and professions. One of the first major uses of project management as we know it today was to manage the United States space programme. The government, military and corporate world have now adopted this practice. Here is the main definition of what project management is:

Project management is no small task.
Project management has a definite beginning and end. It is not a continuous process.
Project management uses various tools to measure accomplishments and track project tasks. These include Work Breakdown Structures, Gantt charts and PERT charts.
Projects frequently need resources on an ad-hoc basis as opposed to organisations that have only dedicated full-time positions.
Project management reduces risk and increases the chance of success.

Project management is often summarised in a triangle. The three most important factors are time, cost and scope, commonly called the triple constraint. These form the vertices with quality as a central theme.

Projects must be delivered on time.
Projects must be within cost.
Projects must be within scope.
Projects must meet customer quality requirements.

More recently, this has given way to a project management diamond, with time, cost, scope and quality the four vertices and customer expectations as a central theme. No two customers' expectations are the same so you must ask what their expectations are.

A project goes through six phases during its life:

Project Definition: Defining the goals, objectives and critical success factors for the project.
Project Initiation: Everything that is needed to set-up the project before work can start.
Project Planning: Detailed plans of how the work will be carried out including time, cost and resource estimates.
Project Execution: Doing the work to deliver the product, service or desired outcome.
Project Control: Ensuring that a project stays on track and taking corrective action to ensure it does.
Project Closure: Formal acceptance of the deliverables and disbanding of all the elements that were required to run the project.

The role of the project manager is one of great responsibility. It is the project manager's job to direct, supervise and control the project from beginning to end. Project managers should not carryout project work, managing the project is enough. Here are some of the activities that must be undertaken:

The project manager must define the project, reduce it to a set of manageable tasks, obtain appropriate resources and build a team to perform the work.
The project manager must set the final goal for the project and motivate his/her team to complete the project on time.
The project manager must inform all stakeholders of progress on a regular basis.
The project manager must assess and monitor risks to the project and mitigate them.
No project ever goes exactly as planned, so project managers must learn to adapt to and manage change.

A project manager must have a range of skills including:

Leadership
People management (customers, suppliers, functional managers and project team)
Effective Communication (verbal and written)
Influencing
Negotiation
Conflict Management
Planning
Contract management
Estimating
Problem solving
Creative thinking
Time Management

"Project managers bear ultimate responsibility for making things happen. Traditionally, they have carried out this role as mere implementers. To do their jobs they needed to have basic administrative and technical competencies. Today they play a far broader role. In addition to the traditional skills, they need to have business skills, customer relations skills, and political skills. Psychologically, they must be results-oriented self-starters with a high tolerance for ambiguity, because little is clear-cut in today's tumultuous business environment. Shortcomings in any of these areas can lead to project failure." - J. Davidson Frame

Many things can go wrong in project management. These things are often called barriers. Here are some possible barriers:

Poor communication
Disagreement
Misunderstandings
Bad weather
Union strikes
Personality conflicts
Poor management
Poorly defined goals and objectives

A good project management discipline will not eliminate all risks, issues and surprises, but will provide standard processes and procedures to deal with them and help prevent the following:

Projects finishing late, exceeding budget or not meeting customer expectations.
Inconsistency between the processes and procedures used by projects managers, leading to some being favoured more than others.
Successful projects, despite a lack of planning, achieved through high stress levels, goodwill and significant amounts of overtime.
Project management seen as not adding value and as a waste of time and money.
Unforeseen internal and/or external events impacting the project.

Project management is about creating an environment and conditions in which a defined goal or objective can be achieved in a controlled manner by a team of people.

PCM

2008-12-16T14:17:00.001-08:00

Project Cycle Management (PCM)

Since recently, a rumor trickles through the scene, which sounds like: "GTZ replaces ZOPP through PCM!", and: "PCM is nothing else than ZOPP - old vine in new bottles!" Both statements are principally wrong but bear - like all rumors - a true core. So, what's that all about?

In the middle of the eighties, GTZ (Deutsche Gesellschaft für Technische Zusammenarbeit) - the main agency for execution of the Technical Collaboration of the German Government, introduced a standardized project planning method. This method consisted of consecutive steps for appraisal, planning, implementation, monitoring and evaluation of projects. This steps were mediated and facilitated by a planning tool that was called ZOPP (Zielorientierte Projektplanung - Objectives Oriented Project Planning). The ZOPP was meant to structure the planning approach into stakeholders analysis, problem analysis, objectives and alternatives analysis and into the project planning matrix (PPM), also known as Logical Framework Approach.

The planning procedure was formalized, and a series of planning workshops were made obligatory for the live cycle of every project. Soon after introduction of ZOPP everybody mistook the workshops with the method without considering the ZOPP as a flexible tool, but as a rigidly structured 3-days or 5-days seminar that started with the participation analysis and ended with the formulation of indicators and assumptions.

During the last ten years, many GTZ advisors and consultants working for GTZ got acquainted with the ZOPP workshop approach; and the monitoring and reporting system was totally adapted to the outcome of the workshop. If a project failed to achieve its planned results, blame could be placed on the external assumptions which had not be met. Nevertheless, since the introduction of ZOPP, critique had never stopped, and at the beginning of the nineties, time was due for a change.

The GTZ recently has introduced a new concept of project management that might have significant consequences for the work of consultants, and which could change the general approach to project planning and implementation. It followed the earlier step of the European Union. This concept which received the label "Project Cycle Management" (PCM) aims at initiating not less than a paradigm shift for the comprehension of "technical assistance" and should not leave anybody untouched of those who deal with development assistance.

The PCM concept incorporates the application of project planning and appraisal tools like ZOPP, PRA (Participatory Rural Appraisal), gender-analysis and others. These tools are not replaced by PCM but put into a flexible context of a planning cycle.

The core of the philosophy of Project Cycle Management is based on the principle that the initiative for a technical cooperation project must be born from a self-help development process, in which only the genuine actors, are involved.

Figure 1: Project Cycle Management

Only if the actors are unable to effect the transfer from the present problem state to the desired state, a national governmental or non-governmental organization might interfere and assist the process for a limited period of time. This is called a project.

Only if the national organization of the partner country is short of the required skills and inputs for the project, the German government might interfere and support the project through technical assistance. A project supported by GTZ always is mediated by the partner organization to the beneficiaries.

This philosophy is not new. In fact it has been the official language of German development policy for the last twenty years, but new is that the GTZ has put it into the focus of the attention. In the past and in the present, projects in most cases have been strongly influenced by the perception of German experts. Official programmes called for participation of beneficiaries, and new tools were introduced that seemed to secure involvement of target groups. However, participation was often reduced to a symbolic application of participatory rural appraisal (PRA). The validity and the applicability of this method often was not related to the context but used as a blueprint approach.

There is a constant inherited conflict that runs through nearly all projects: target groups and partner organizations often, if not mostly have a different perception of projects, different desires, different technical concepts. If partner organizations would plan projects on their own, those would look different. UNDP has already introduced its new concept of "national execution" of projects. I had the opportunity to observe such a project in Thailand, which was, among other components, to support small-scale milk production. The project had highest support - the king of Thailand himself. Although officially it was called a "poverty alleviation project", the main rationale was to reduce the Thai dependency on imports of dairy products. Therefore the project was not questioned for a long time. Through heavy subsidizes to feedstuffs, extension, animal health services, and credits, production was economically feasible for a period of time. However, the high performance breeds introduced were not adopted to the extreme climate and the restricted feeding during the long dry season; their milk yield was sub-optimum. Finally, the prices for concentrate feeds which were constantly rising, exceeded the limit that allowed feasible production. Farmers who in the past were either forced or attracted through the subsidies started to protest and refused to continue dairying.

If there is any economic or moral sense justifying development assistance, one question should be allowed:

Are we (the experienced experts from the North) smarter?

Sitting in my German office, I really don't know. Working in a particular concept as a consultant, of course, I am convinced that I am; otherwise I could not justify to work for a salary which is sometimes hundred times higher than the salary that my counterpart receives.

If I look at the results of development aid of the last decades, I doubt that we are smarter. Maybe we are better sometimes, and our solar cookers look very fancy, but our project approaches often were not really accepted by the "target groups" and our partners. This relates to mainstream and so-called "alternative" project approaches. We all know that the predominant view of partner governments and partner organizations is: "We don't love the foreign experts, but we accept them as long as there is money involved."

Despite of all different approaches that have been tried out since social-democratic values form the base of development assistance - AT, participation, etc. - sustainability of projects which are based on foreign experts or volunteers has not improved significantly.

There are some challenging questions for the coming years to be answered:

What can we do to increase acceptance of advisory service?
How can we make ourselves better understandable to our partners, making them truly believe that we come with best intentions?
Do we, the experts, have to change radically our concept of Technical Assistance?
How can we and our partners work together as a real great team, sharing responsibility and using all our creativity?

In this sense, the task of consultants in development assistance will be more process oriented. Ideally, they could be unbiased observers, who visit a project periodically, facilitate real participation of all actors and help to bring peoples brains and hearts together - not only including the poor farmers, but also the national experts and bureaucrats. Such a consultant would first of all need social competence and secondly the ability to move to a meta-level, i.e. to step back and to critically assess the roles of the participants - including his/her own. The long-term advisers acting as team leaders in German Technical Assistance projects will in many cases be overburdened with the triple responsibility of giving technical advise, organizing personnel and material inputs, and managing social processes. Consultants might in future act as process supervisors and personal coaches to project managers.

The Objective Oriented Project Planning method is released from its straitjacket and positioned into a process. That means that planning workshops will not be obligatory any more within the project cycle - the German teamleader or backstopper can decide . If workshops are conducted, the decision on the applied methods is up to the moderator. They have to be chosen according to the status of the project. At a certain period of time, it might be necessary to do a problem analysis in a workshop, at a different point of time, a group might work on the project vision or elaborate the project planning matrix. But things could be done also without workshops, e.g. in small project groups. For example, a stakeholders analysis will require detailed studies which might include application of tools like PRA and gender analysis. The project team is free to apply other tools like vision sharing, future conferences, etc. However, the project planning matrix will most likely remain as an important tool of quality control and as a base for operational planning, monitoring and evaluation . Indicators will become a base to reach a common understanding on the project quality between advisers and partners ("What is it that we want to achieve?").

The artistry in planning

2008-12-16T14:16:00.000-08:00

At the planning stage, you can deal with far more than the mere project at hand. You can also shape the overall pattern of your team's working using the division and type of activities you assign.

Who know best?

Ask your team. They too must be involved in the planning of projects, especially in the lower levels of the work breakdown structure. Not only will they provide information and ideas, but also they will feel ownership in the final plan.

This does not mean that your projects should be planned by committee - rather that you, as manager, plan the project based upon all the available experience and creative ideas. As an initial approach, you could attempt the first level(s) of the work breakdown structure to help you communicate the project to the team and then ask for comments. Then, using these, the final levels could be refined by the people to whom the tasks will be allocated. However, since the specification is so vital, all the team should vet the penultimate draft.

Dangers in review

There are two pitfalls to avoid in project reviews:

they can be too frequent
they can be too drastic

The constant trickle of new information can lead to a vicious cycle of planning and revising which shakes the team's confidence in any particular version of the plan and which destroys the very stability which the structure was designed to provide. You must decide the balance. Pick a point on the horizon and walk confidently towards it. Decide objectively, and explain beforehand, when the review phases will occur and make this a scheduled milestone in itself.

Even though the situation may have changed since the last review, it is important to recognise the work which has been accomplished during the interim. Firstly, you do not want to abandon it since the team will be demotivated feeling that they have achieved nothing. Secondly, this work itself is part of the new situation: it has been done, it should provide a foundation for the next step or at least the basis of a lesson well learnt. Always try to build upon the existing achievements of your team.

Testing and Quality

No plan is complete without explicit provision for testing and quality. As a wise manager, you will know that this should be part of each individual phase of the project. This means that no activity is completed until it has passed the (objectively) defined criteria which establishes its quality, and these are best defined (objectively) at the beginning as part of the planning.

When devising the schedule therefore you must include allocated time for this part of each activity. Thus your question is not only: "how long will it take", but also: "how long will the testing take". By asking both questions together you raise the issue of "how do we know we have done it right" at the very beginning and so the testing is more likely to be done in parallel with the implementation. You establish this philosophy for your team by include testing as a justified (required) cost.

Fitness for purpose

Another reason for stating the testing criteria at the beginning is that you can avoid futile quests for perfection. If you have motivated your team well, they will each take pride in their work and want to do the best job possible. Often this means polishing their work until is shines; often this wastes time. If it clear at the onset exactly what is needed, then they are more likely to stop when that has been achieved. You need to avoid generalities and to stipulate boundaries; not easy, but essential.

The same is also true when choosing the tools or building-blocks of your project. While it might be nice to have use of the most modern versions, or to develop an exact match to your needs; often there is an old/existing version which will serve almost as well (sufficient for the purpose), and the difference is not worth the time you would need to invest in obtaining or developing the new one. Use what is available whenever possible unless the difference in the new version is worth the time, money and the initial, teething pains.

A related idea is that you should discourage too much effort on aspects of the project which are idiosyncratic to that one job. In the specification phase, you might try to eliminate these through negotiation with the customer; in the implementation phase you might leave these parts until last. The reason for this advice is that a general piece of work can be tailored to many specific instances; thus, if the work is in a general form, you will be able to rapidly re-use it for other projects. On the other hand, if you produce something which is cut to fit exactly one specific case, you may have to repeat the work entirely even though the next project is fairly similar. At the planning phase, a manager should bare in mind the future and the long-term development of the team as well as the requirements of the current project.

Fighting for time

As a manager, you have to regulate the pressure and work load which is imposed upon your team; you must protect them from the unreasonable demands of the rest of the company. Once you have arrived at what you consider to be a realistic schedule, fight for it. Never let the outside world deflect you from what you know to be practical. If they impose a deadline upon you which is impossible, clearly state this and give your reasons. You will need to give some room for compromise, however, since a flat NO will be seen as obstructive. Since you want to help the company, you should look for alternative positions.

You could offer a prototype service or product at an earlier date. This might, in some cases, be sufficient for the customer to start the next stage of his/her own project on the understanding that your project would be completed at a later date and the final version would then replace the prototype.

The complexity of the product, or the total number of units, might be reduced. This might, in some cases, be sufficient for the customer's immediate needs. Future enhancements or more units would then be the subject of a subsequent negotiation which, you feel, would be likely to succeed since you will have already demonstrate your ability to deliver on time.

You can show on an alternative schedule that the project could be delivered by the deadline if certain (specified) resources are given to you or if other projects are rescheduled. Thus, you provide a clear picture of the situation and a possible solution; it is up to your manager then how he/she proceeds.

Planning for error

The most common error in planning is to assume that there will be no errors in the implementation: in effect, the schedule is derived on the basis of "if nothing goes wrong, this will take ...". Of course, recognising that errors will occur is the reason for implementing a monitoring strategy on the project. Thus when the inevitable does happen, you can react and adapt the plan to compensate. However, by carefully considering errors in advance you can make changes to the original plan to enhance its tolerance. Quite simply, your planning should include time where you stand back from the design and ask: "what can go wrong?"; indeed, this is an excellent way of asking your team for their analysis of your plan.

You can try to predict where the errors will occur. By examining the activities' list you can usually pinpoint some activities which are risky (for instance, those involving new equipment) and those which are quite secure (for instance, those your team has done often before). The risky areas might then be given a less stringent time-scale - actually planning-in time for the mistakes. Another possibility is to apply a different strategy, or more resources, to such activities to minimise the disruption. For instance, you could include training or consultancy for new equipment, or you might parallel the work with the foundation of a fall-back position.

Post-mortem

At the end of any project, you should allocate time to reviewing the lessons and information on both the work itself and the management of that work: an open meeting, with open discussion, with the whole team and all customers and suppliers. If you think that this might be thought a waste of time by your own manager, think of the effect it will have on future communications with your customers and suppliers.