Successful Technical Project Management

April 29, 2009 by  Filed under: Management 


This paper provides ten useful tips for successful project management, distilled from years of experience in deploying enterprise business software solutions. Delivering success, on time and on budget, requires not only the ability to follow a process, but also people skills, the ability to achieve compromise, and the ability to foresee, avoid and overcome technical issues.

Project management methodologies provide a process framework, organisational discipline, and predefined terminology to avoid miscommunication. A project manager’s job is not just to build a project plan and track progress; that would be too easy.

1. Establish the project’s business requirements and success criteria

Understand which stakeholders are driving which business requirements, and understand the relative importance of each requirement. Understanding the underlying business requirements will help steer the project to success which, in the end, is all about delivering business value.

Business requirements should be expressed in terms of SMART business goals. SMART goals are usually defined as being:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-bound

While business requirements need to be more specific they may be based on one or several of the following:

  • Ensuring customers can get consistent and accurate information, quickly and easily.
  • Reducing service delivery or production costs.
  • Improving customer retention by improving product quality.
  • Improving customer retention by improving customer service.
  • Ensuring regulatory compliance; for example protecting confidential information from misuse or theft.

For large projects, which may run for 12 months or more, business requirements should be reviewed at appropriate intervals to ensure that the project is keeping up with any changes in priority, emphasis or perception, and that judgements regarding business benefit and return on investment are revalidated.

2. Define, and be able to justify, all the functional requirements

Be clear how each requirement will contribute to reaching the business goals, and contribute to providing a return on investment for the project.

Functional requirements should express what the system will actually do, but not how it will be implemented. While implementation design logically comes later, implementation cost is a consideration to ensure that the project will deliver a return on investment.

If the estimated implementation cost of a specific functional requirement isn’t going to provide a return on investment then an alternative needs to be found through a different combination or selection of technologies and/or manual processes.

Functional requirements should be clear and distinct such that each can be prioritised, tracked and measured and, where appropriate, responsibility delegated.

3. Understand the business-as-usual working environment

For any software solution the business environment includes:

  • People and Organisational Units
  • Policies, Processes and Procedures
  • Technology

A successful project requires an understanding of how the new or updated solution will work with all of the above. For a software project, technology (hardware, software, networks etc.) is hard to ignore, and the solution will usually be made to function; but other considerations can be equally important for it to really deliver on its business goals.

A new solution can fail to deliver benefit if:

  • Users don’t know how or when to use it.
  • Users don’t use it because they don’t like it, or trust it.
  • Support staff don’t know how to support the solution’s users.
  • Operations staff don’t know how to maintain it and ensure it stays working.

Software solutions need to operate within an existing technology landscape. Compatibility, interoperability and security issues need to be considered. Consideration also needs to be given to the way this landscape is expected to change to ensure the solution will deliver lasting benefit.

4. Understand the implementation design options available

Functional requirements can invariably be implemented in many ways, using different combinations of platforms, products, configurations, and customisations.

Often these choices are rightly limited by previous decisions which have already been made. Companies have preferred suppliers, existing license agreements, and existing in-house skill sets. These preferences improve predictability and reduce risk by ensuring that the required experience is available.

Using completely new technologies can have benefits which can lead to competitive advantages, but doing so should be done with caution. New technologies should be thoroughly evaluated to determine their suitability, reliability and cost effectiveness.

5. Use all the available experience

Success requires teamwork. Identify and engage with the people who will be responsible for bring about all the necessary changes to the systems, processes and procedures impacted by the project.

Engaging with these people early is critical to success as:

  • They have real and relevant experience about what needs to change, how to make change, how long it might take, and what issues you might face; and they can therefore help you plan effectively.
  • They will resist change, and be less inclined to provide favours, unless they are well informed, and feel valued.

The more experience you can draw upon the greater your success. For example, experience with:

* The company’s culture, processes and procedures.

– How do you get things done?

– What are the sticking points and bottlenecks?

* Particular technologies, platforms or software vendors

– What is tried and tested?

– What is unusual or risky?

* Particular business functions or market sectors

– What is mandatory? Important? Safely ignored?

Asking for help is not a sign of weakness. The goal is to get the project delivered. You will be judged on successful project delivery not whether you heroically achieved it on your own at great personal sacrifice.

6. Communicate regularly in both written and verbal form

Many people rely on email simply out of habit, rather than picking up the phone. Verbal, and face to face, communication is often clearer and more efficient. Email should be used to confirm agreements and communicate decisions, but it should not be used as a discussion forum; doing so creates a large amount of information-poor correspondence which quickly becomes hard to manage.

Written communication is essential to record business and functional requirements, implementation designs, choices and decisions, and issues and risks. Written information should be concise; more is not always better.

Documents should go through a formal review and sign-off process. The process itself improves communication and reduces risk, as well as providing a formal record.

Communicating risks and issues is an important part of project communication. However repetitive review of long, growing lists can be a sign of an unhealthy project; not because the issues and risks arise but because they are not being dealt with. Action should be taken promptly to mitigate risks and resolve issues; once mitigated or resolved they should not need to remain on the list. Items which remain on a risk or issue list for a long period should stick out like a sore thumb.

7. Don’t assume that everything will go well, because it won’t

Everything will not go well, so don’t assume that it will, particularly in your planning. Assumptions will be proven false, software will have bugs, people will get sick or leave, unforeseen changes will be required.

Because of this, take the following steps:

  • Actively plan to challenge and dispose of every assumption as early as possible
  • Review lists of known bugs or issues which can be obtained from relevant suppliers
  • Plan to exercise software features you plan to use to flush out any issues which may impact your project. (This can also serve as a self learning / training opportunity.)
  • You should be aware of the maintenance policies and release plans of the software vendors. This will allow you to determine whether any bugs found could be fixed within the timescales required, and what action you may need to take if they cannot be addressed.

8. Define your quality assurance and testing approach early

The process, timescales and resources for quality assurance and testing should be agreed well in advance. This may be agreed during the initial planning stages, but should be reviewed after the functional and implementation design phases. Leaving it until the implementation phase is complete is way too late!

In order to keep to committed milestone dates, it is not uncommon to reduce the time available for testing, and in the process incur additional quality risks. Doing so rarely results in reducing the testing and quality improvement effort, it merely defers it until your users are already experiencing the quality issues the original planned effort intended to avoid. This is usually avoidable; but if it is to happen then make sure that the resources remain available after launch to handle it.

9. Take great care in planning system changes to minimise the risk of disruption

The final steps to rollout out a new or revised system should go ahead without issue, with sufficient preparation, but it is necessary to be prepared for the unexpected. As we cannot know what the unexpected might be there are just two things we should do.

  1. Make sure everyone involved in the project is aware when changes are going to be made, and that they can be made available to resolve issues and/or answer questions promptly if necessary.
  2. Make sure all the systems involved can be restored to their original state should any significant failures arise which cannot be resolved quickly – this includes having the right people with right authority available to restore the systems; being able to restore a system in theory is no good if you cannot do so in practice.

10. Plan for post launch activities

Once a system has been launched it should become part of the normal operations of the company.

However it is likely that:

  • There are some improvements or capabilities which didn’t make the first cut.
  • Performance measurements need to be made to confirm that it is delivering all the benefits it was originally intended to deliver.
  • During early activities, as the system “beds down”, lessons will be learned and observations made, which could lead to further improvements or optimisations.

The above items are actually more than likely, they are a certainty. So it is better to have some time already in the plan and budget to allow for them. While such items can be budgeted for later, doing so will likely cause delay. Further, if the launch is part of a multi-phased project or program, these items will have a knock on effect, causing further delay downstream.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

You must be logged in to post a comment.

Prev Post:
Next Post: