Project Management Tips for Successful Projects

Plan for Success

Your project management plan is your bible for success. Without it, there will not be a project because without a workable plan, you have no way to reach your goal. Your plan must start at with the goal that you want to achieve. Then, break down that go into workable segments. Set a timeline for each segment. Your team should know these timelines and adhere to them. This does not mean that you make a mad dash between segments. You want to allow enough time for these various stages to be achieved while still being able to meet the overall deadline. Remember, you can rework your plan to find better ways to get you where you need to be.

Key Performance Indicators (KPI)

Key performance indicators are those little segments that let you know you’re moving forward and moving towards achieving your goal. You want to set KPI’s that can be measured and realistically attained. Set your team up for success and not failure by constantly monitoring the key indicators. This can also be a benchmark tool to use on future projects to determine success. If you have been on a project that has failed then you know some of the KPI’s that should have been in place to have effectively evaluated the progress of the project. The easiest way to build KPI’s into your project is to put them into the schedule as critical tasks. That way you can track your performance indicators as part of your timeline. Its like a built in reminder system to check on the health of your project.

5 Key Factors for Project Success.
So how do you keep a project moving toward success?

1. Know exactly what your project is trying to achieve.
2. Plan effectively to reach your overall goal.
3. Keep open communications amongst team members.
4. Have a Q & A session at various stages to see if the plan needs to be revised to achieve the goal.
5. Motivate team members. After all, they are working hard to help you achieve the project’s goal.

Being a project manager is a lot of work. However, when you’ve see a project through to success, then it is all worth it. Success can “always” be attained if you have the proper plan in place, good communications between team members and flexibility to change the plan as needed –without compromising the timeline.

Top 10 Tips for Successful Software Development Management

by Jack Bicer

71% of the software projects do not succeed!

Here are some time tested guidelines that have been used extensively to deliver web

development projects successfully, on-time and on-budget. Although most of the

projects developed are between 1 to 10 man years of effort, these tips also scale nicely

for smaller projects of 2 man months to larger projects of 25 man years.

1. Understand the user’s needs, write the specs before coding and keep them up to date. Develop the User Interface with the specs and flush out design issues.
2. Break projects into modules of 1 week or shorter.
3. Implement risky modules early.
4. Create validation milestones, every 3 to 4 weeks.
5. Provide the necessary resources.
6. Get developer buy-in for features, timelines and milestones.
7. Keep people accountable to their commitments.
8. Resist “feature creep” during implementation and testing.
9. Use automated functional testing tools and do stress testing.
10. Under-promise, over-deliver and plan a pleasant surprise at the end.

In every project, one or more of these guidelines will be broken. A breach of a guideline does not mean a project will be unsuccessful. Other guidelines will usually pull you through and help the project succeed. It is the large number of breaches and the depth of the breaches that will create project failures.

Michael Greer - Ten Guaranteed Ways to Screw Up Any Project

1. Don’t bother prioritizing your organization’s overall project load. After all, if there’s a free-for-all approach to your overall program management (i.e., “survival of the fittest”), then the projects that survive will be those that were destined to survive. In the meantime, senior management need not trouble themselves aligning projects with strategic goals or facing the logical imperative that people simply cannot have 12 number one priorities! 
2. Encourage sponsors and key stakeholders to take a passive role on the project team. Let them assert their authority to reject deliverables at random, without participating in defining project outcomes in a high-resolution fashion. And above all, don’t bother project sponsors when their constituents (such as key SMEs and reviewers) drop the ball and miss their deadlines.
3. Set up ongoing committees focusing on management process (such as TQM groups, etc.) and make project team members participate in frequent meetings and write lots of reports… preferably when critical project deadlines are coming due.
4. Interrupt team members relentlessly … preferably during their time off. Find all sorts of trivial issues that “need to be addressed,” then keep their beepers and cell phones ringing and bury them in emails to keep them off balance.
5. Create a culture in which project managers are expected to “roll over” and take it when substantive new deliverables are added halfway through the project. (After all, only a tradesperson like a plumber or electrician would demand more money or more time for additional services; our people are “professionals” and should be prepared to be “flexible.”)
6. Half way through the project, when most of the deliverables have begun to take shape, add a whole bunch of previously unnamed stakeholders and ask them for their opinions about the project and its deliverables.
7. Encourage the sponsor to approve deliverables informally (with nods, smiles, and verbal praise); never force sponsors to stand behind their approvals with a formal sign-off. (In other words, give ‘em plenty of room to weasel out of agreements!)
8. Make sure project managers have lots of responsibilities and deadlines, but no authority whatsoever to acquire or remove people from the project; to get enough money, materials, or facilities; or insist on timely participation of SMEs and key reviewers.
9. Describe project deliverables in the vaguest possible terms so sponsors and reviewers have plenty of leeway to reinvent the project outputs repeatedly as the project unfolds.
10. Get projects up and running as quickly as possible – don’t worry about documenting agreements in a formal project charter, clearly describing team roles/responsibilities, or doing a thorough work breakdown analysis. After all, we know what we’re doing and we trust each other. So let’s get to it without a pesky audit trail!

Michael Greer's 14 Key Principles for Project Mgt. Success

This web-published article by Michael Greer is an excerpt from ” Handbook of Human Performance Technology, San Francisco, Jossey-Bass, 1999

1. Project managers must focus on three dimensions of project success.Simply put, project success means completing all project deliverables ontime, within budget, and to a level of quality that is acceptable to sponsors and stakeholders. The project manager must keep the team’s attention focused on achieving these broad goals.
2. Planning is everything — and ongoing. On one thing all PM texts and authorities agree: The single most important activity that project managers engage in is planning — detailed, systematic, team-involved plans are the only foundation for project success. And when real-world events conspire to change the plan, project managers must make a new one to reflect the changes. So planning and replanning must be a way of life for project managers.
3. Project managers must feel, and transmit to their team members, a sense of urgency. Because projects are finite endeavors with limited time, money, and other resources available, they must be kept moving toward completion. Since most team members have lots of other priorities, it’s up to the project manager to keep their attention on project deliverables and deadlines. Regular status checks, meetings, and reminders are essential.
4. Successful projects use a time-tested, proven project life cycle. We know what works. Models such as the standard ISD model and others described in this text can help ensure that professional standards and best practices are built into our project plans. Not only do these models typically support quality, they help to minimize rework. So when time or budget pressures seem to encourage taking short cuts, it’s up to the project manager to identify and defend the best project life cycle for the job.
5. All project deliverables and all project activities must be visualized and communicated in vivid detail. In short, the project manager and project team must early on create a tangible picture of the finished deliverables in the minds of everyone involved so that all effort is focused in the same direction. Avoid vague descriptions at all costs; spell it out, picture it, prototype it, and make sure everyone agrees to it.
6. Deliverables must evolve gradually, in successive approximations. It simply costs too much and risks too much time spent in rework to jump in with both feet and begin building all project deliverables. Build a little at a time, obtain incremental reviews and approvals, and maintain a controlled evolution.
7. Projects require clear approvals and sign-off by sponsors. Clear approval points, accompanied by formal sign-off by sponsors, SMEs, and other key stakeholders, should be demarcation points in the evolution of project deliverables. It’s this simple: anyone who has the power to reject or to demand revision of deliverables after they are complete must be required to examine and approve them as they are being built.
8. Project success is correlated with thorough analyses of the need for project deliverables. Our research has shown that when a project results in deliverables that are designed to meet a thoroughly documented need, then there is a greater likelihood of project success. So managers should insist that there is a documented business need for the project before they agree to consume organizational resources in completing it.
9. Project managers must fight for time to do things right. In our work with project managers we often hear this complaint: “We always seem to have time to do the project over; I just wish we had taken the time to do it right in the first place!” Projects must have available enough time to “do it right the first time.” And project managers must fight for this time by demonstrating to sponsors and top managers why it’s necessary and how time spent will result in quality deliverables.
10. Project manager responsibility must be matched by equivalent authority. It’s not enough to be held responsible for project outcomes; project managers must ask for and obtain enough authority to execute their responsibilities. Specifically, managers must have the authority to acquire and coordinate resources, request and receive SME cooperation, and make appropriate, binding decisions which have an impact on the success of the project.
11. Project sponsors and stakeholders must be active participants, not passive customers. Most project sponsors and stakeholders rightfully demand the authority to approve project deliverables, either wholly or in part. Along with this authority comes the responsibility to be an active participant in the early stages of the project (helping to define deliverables), to complete reviews of interim deliverables in a timely fashion (keeping the project moving), and to help expedite the project manager’s access to SMEs, members of the target audience, and essential documentation.
12. Projects typically must be sold, and resold. There are times when the project manager must function as salesperson to maintain the commitment of stakeholders and sponsors. With project plans in hand, project managers may need to periodically remind people about the business need that is being met and that their contributions are essential to help meet this need.
13. Project managers should acquire the best people they can and then do whatever it takes to keep the garbage out of their way. By acquiring the best people — the most skilled, the most experienced, the best qualified — the project manager can often compensate for too little time or money or other project constraints. Project managers should serve as an advocate for these valuable team members, helping to protect them from outside interruptions and helping them acquire the tools and working conditions necessary to apply their talents.
14. Top management must actively set priorities. In today’s leaner, self-managing organizations, it is not uncommon for project team members to be expected to play active roles on many project teams at the same time. Ultimately, there comes a time when resources are stretched to their limits and there are simply too many projects to be completed successfully. In response, some organizations have established a Project Office comprised of top managers from all departments to act as a clearinghouse for projects and project requests. The Project Office reviews the organization’s overall mission and strategies, establishes criteria for project selection and funding, monitors resource workloads, and determines which projects are of high enough priority to be approved. In this way top management provides the leadership necessary to prevent multi-project log jams. 

Programming: Object Oriented Design Tips

Here is an assortment of tips to keep in mind when using object oriented design in embedded systems:

1. Stay close to problem domain
2. Object discovery vs. object invention
3. Pick nouns or noun phrases as classes
4. Method names should contain a verb
5. Prefix adjectives when naming inheriting classes
6. Do not add suffixes to class names
7. Avoid one-to-one mapping from structured design
8. Replace multiple get-set methods with operations
9. Model classes that handle messages as state machines
10. Use const whenever possible
11. Restrict header file level dependency

Stay close to problem domain

Design is a process of modeling the problem domain into programming constructs. Object oriented design simplifies the design process by maintaining a one-to-one mapping between problem domain objects and software objects. To succeed in object oriented design, keep your design as close as possible to problem domain objects. The interactions between your objects should mirror interactions between corresponding problem domain objects.
Problem domain objects is basically an object that can be found in the problem itself. For example, when developing a text editor real-world objects would be, Paragraph, Sentence, Word, ScrollBar, TextSelection etc. While developing a call processing module, the objects might be Call, Ringer, ToneDetector, Subscriber etc.

Object discovery vs. object invention

The first step in object oriented analysis is to discover the objects that can be directly identified from the problem itself. In many cases objects can be identified  from the requirements. Objects discovered from the problem statement are extremely important. These objects will be the core objects in the design.
The next stage in object design is to "invent" objects. These objects are needed to "glue" together objects that have been identified during object discovery. Invented objects generally do not correspond to anything tangible in the problem domain. They are inventions of programmers to simplify design.
Consider the following statement from the requirements:
The circuit controller shall support digital and analog circuits. The circuit controller shall contain 32 DSPs. When the circuit controller receives a request to setup a circuit, it shall allocate a DSP to the circuit.
We discover the following objects from the requirement:

• CircuitController
• DigitalCircuit
• AnalogCircuit
• DSP

We invent the following objects based on our knowledge of the manager design pattern:

• DSPManager: Manages the 32 DSPs on the circuit controller
• CircuitManager: Manages the digital and analog circuits

We invent a Circuit base class for DigitalCircuit and AnalogCircuit by filtering properties that are common to DigitalCircuit and AnalogCircuit objects.
The relationship between the classes also follows from the requirement. CircuitController class contains DSPManager and CircuitManager classes. TheCircuitManager contains an array of Circuit class pointers. The DSPManager contains an array of DSP objects.

Pick nouns or noun phrases as classes

Identifying objects is easy, they should always be nouns. As we have seen in the Circuit Controller example, we picked up nouns from the requirements as classes in our design. Even when you invent classes, keep in mind that they should be nouns. Abstract concepts don't qualify as object names.
Naming the objects is extremely important in object oriented design. Chances are that if you name your object correctly, the designers and maintainers will assign it functionality that fits its name. Also note that, if you have trouble naming an object, you probably have the wrong object. At this point go back and look at the problem again and see if you can pick an alternative object.

Method names should contain verbs

In any language, actions performed by nouns are specified using verbs. Why should object oriented programming be any different? Thus make sure all the operation methods should contain verbs.
Thus the Circuit class we discussed earlier would have methods like:

• Activate
• Deactivate
• Block
• Unblock
• ChangeStatus

Notice that the methods do not include Circuit in the name (ActivateCircuit, BlockCircuit etc.) as being methods of Circuit its clear that they refer to operations on Circuit.

Prefix adjectives when naming inheriting classes

This one is fairly obvious. When a class inherits from a base class, the name for the new class can be determined just by prefixing it with the appropriate adjective. For example, classes inheriting from Circuit are called AnalogCircuit and DigitalCircuit. Following this convention leads to class names that convey information about the classes inheritance.

Do not add suffixes to class names

Do not add suffixes like Descriptor, ControlBlock, Agent to the class names. For example,  DigitalCircuit should not be called DigitalCircuitDescriptor or DigitalCircuitControlBlock. Such names are longer and do not convey the exact role of the class.

Avoid one-to-one mapping from structured design

Many developers moving from structured design just continue with structured design in C++. The classes developed correspond more to similar structured constructs they have used in the past. Similarity between C and C++ confuses developers. Make no mistake, object oriented programming is a completely different technique. The emphasis here is to keep the design process simple by minimizing the difference between the problem domain and software domain.

Replace multiple get-set methods with operations

Developers complain that after moving to object oriented programming, they spend considerable time writing mindless get and set methods. Here is a simple tip on reducing the get and set methods. Consider the code below:

Circuit Status (Multiple Get-Set)

void CircuitManager::GetStatus(const CircuitStatusMsg *pMsg) const { for (int i= 0; i < MAX_CIRCUITS; i++) { pMsg->circuitInfo[i].circuitId = m_pCircuit[i]->GetId(); pMsg->circuitInfo[i].circuitType = m_pCircuit[i]->GetType(); pMsg->circuitInfo[i].circuitStatus = m_pCircuit[i]->GetStatus(); pMsg->circuitInfo[i].circuitCallId = m_pCircuit[i]->GetCallId(); pMsg->circuitInfo[i].circuitState = m_pCircuit[i]->GetState(); } }

The above code can be replaced by moving the field filling in the message to the Circuit class. This way you do not need to define a large number of get operations. Also, any changes in the CircuitInfo field would result only in changes to the Circuit class. CircuitManager would be transparent as it does not look into CircuitInfo.

Circuit Status (Single Operation)

void CircuitManager::GetStatus(const CircuitStatusMsg *pMsg) const { for (int i= 0; i < MAX_CIRCUITS; i++) { m_pCircuit[i]->UpdateStatus(pMsg->circuitInfo[i]); } } void Circuit::UpdateStatus(CircuitInfo &circuitInfo) const { circuitInfo.circuitId = m_id; circuitInfo.circuitType = m_type; circuitInfo.circuitStatus = m_status; circuitInfo.circuitCallId = m_callId; circuitInfo.circuitState = m_state; }

Model classes that handle messages as state machines

Whenever you encounter a class that has to perform some level of message handling, its always better to model it as a state machine.

Use const whenever possible

C++ provides powerful support for const methods and fields. const should be used in the following cases:

• Methods that do not change the value of any variable in the class should be declared const methods.
• If a function is supposed to just read information from a class, pass a const pointer or reference to this function. The called function would be restricted to calling const methods and using the classes fields only on the right side of an expression.

Proper and consistent use of const will help you catch several bugs at compile time. So start using const from day one of your project.  If const is not used extensively from the beginning of a project, it will be close to impossible to add it later.

Restrict header file level dependency

Complex software requires a careful header file management even when programming in C. When developers move to C++, header file management becomes even more complex and time consuming. Reduce header file dependency by effective use of forward declarations in header files. Sometimes to reduce header file dependency you might have to change member variables from values to pointers. This might also warrant  changing inline functions to out-of-line functions. Every time you use a #include make sure that you have an extremely good reason to do so.

7 Steps to Project Success 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:

1. Profit from your project
2. Rally support
3. Organise plans, resources, etc
4. Focus on key benefits
5. Invoke risk responses in advance
6. Test your project is working
7. 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!

Peter Draper is an executive coach for project managers, globally via phone/email - providing systematic coaching support for already successful people. Further information available from www.linkedin.com/in/peterdraper 

Programming - Liberating The Bug

It's inevitable for programmers to run into a programming bug that is difficult to pin down. The most difficult are:

⁃ Time or Timing related: the bug only shows up at certain times, or based on other time-related events

⁃ Secondary or Tertiary: The bug only shows up when one or a series of other events occur

⁃ Hardware related: the bug only shows up when a hardware event occurs, such as an I2C event

I've seen programmers get lost trying to cause and track-down these kinds of bugs. In fact I managed a project that ran 2 months late because the programmer had a tertiary bug that he chased without telling anyone. OUCH!

There are tactics that can help deal with difficult bugs. I've used these to solve gnarly problems.

⁃ Isolate the problem code: separate the problem code out into a test program. This removes working code from debugging sessions.

⁃ Isolate hardware: When chasing a hardware related bug, remove extraneous hardware from the debugging environment. You don't need to be tracking serial port interrupts when fixing a video refresh bug.

⁃ Look for alternatives: after chasing a bug for a day or two, it's worth looking at coding alternatives. Can the problem code be rewritten taking a different tack? I recently had an RSS decode bug that I resolved by rewriting the code to look for a different header tag. Don't fight the dragon for too long.

Fighting bugs is part of the art of programming. How you deal with pesky bugs determines your ability to finish projects on time, or wallowing in lateness.

Project Management - Identify the Risks

A simple way to keep project from veering off schedule is to identify and plan for risks up front. I've joined countless projects that were running late because "something came up" that took the participants by surprise. It makes so much sense to plan for high risk tasks up front, but it isn't often done.

If your project relies on a new technology, set a strategy for dealing with technology risk. Is there an existing technology that can be substituted if the new technology does not meet expectations on schedule? Is there a way to test the new technology early in the project? Are there multiple tracks that can be used for implementing new and existing technologies?

Company or inter-company issues can be planned for as well. Are there end of quarter issues that could impact the project; and can you plan for them? Do you require something from another company in order to complete the project? Are there tasks that can be run in parallel while you wait for delivery?

Up front planning for risk can save a lot of headaches later in the project. It also make it much easier for a project manager running multiple projects. A little planning up front can go a long way.