Successful Technical Project Management

Successful Technical Project Management
Copyright © 2008 Brandon Cross Technologies Ltd. All rights reserved.
Brandon Cross Technologies Ltd.
23 Eastlands, Lacey Green,
Princes Risborough, Buckinghamshire
HP27 0QB, United Kingdom
Admin: 020 8144 2000
Sales: 07866 436 863
Email: info@brandoncross.co.uk
Company registered in England and Wales No: 5994516 Vat Registration No: 897368647
Successful Technical
Project Management
Contents
Contents...............................................................................................................................................1
Introduction .........................................................................................................................................1
1. Establish the project's business requirements and success criteria ............................................2
2. Define, and be able to justify, all the functional requirements ...................................................2
3. Understand the business-as-usual working environment............................................................3
4. Understand the implementation design options available..........................................................3
5. Use all the available experience...................................................................................................4
6. Communicate regularly in both written and verbal form ............................................................4
7. Don't assume that everything will go well, because it won’t.......................................................5
8. Define your quality assurance and testing approach early..........................................................5
9. Take great care in planning system changes to minimise the risk of disruption .........................5
10. Plan for post launch activities...................................................................................................6
About Brandon Cross Technologies.....................................................................................................6
Introduction
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.

Admin: 020 8144 2000
Sales: 07866 436 863
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.

Admin: 020 8144 2000
Sales: 07866 436 863
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.

Admin: 020 8144 2000
Sales: 07866 436 863
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.

Admin: 020 8144 2000
Sales: 07866 436 863
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

Admin: 020 8144 2000
Sales: 07866 436 863
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
programme, these items will have a knock on effect, causing further delay downstream.
About Brandon Cross Technologies
Brandon Cross Technologies provides flexible technical project management, software integration
and support services; primarily to businesses in the Thames Valley area, with project activities
extending across the UK and EMEA.
Brandon Cross consultants have both the in-depth technical knowledge and the business acumen
to provide the support and insight necessary to navigate through the complexities of software
delivery; enabling businesses to achieve their business goals through effective use of IT.
http://www.brandoncross.co.uk

Successful Technical Project Management

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Successful Technical Project Management

Similaire à Successful Technical Project Management (20)

Dernier

Dernier (20)

Successful Technical Project Management