| Introduction | | | | - They will resist change, and be less inclined to provide |
| This paper provides ten useful tips for successful | | | | favours, unless they are well informed, and feel valued. |
| project management, distilled from years of | | | | The more experience you can draw upon the greater |
| experience in deploying enterprise business software | | | | your success. For example, experience with: |
| solutions. Delivering success, on time and on budget, | | | | * The company's culture, processes and procedures. |
| requires not only the ability to follow a process, but | | | | - How do you get things done? |
| also people skills, the ability to achieve compromise, | | | | - What are the sticking points and bottlenecks? |
| and the ability to foresee, avoid and overcome | | | | * Particular technologies, platforms or software |
| technical issues. | | | | vendors |
| Project management methodologies provide a | | | | - What is tried and tested? |
| process framework, organisational discipline, and | | | | - What is unusual or risky? |
| predefined terminology to avoid miscommunication. A | | | | * Particular business functions or market sectors |
| project manager's job is not just to build a project plan | | | | - What is mandatory? Important? Safely ignored? |
| and track progress; that would be too easy. | | | | Asking for help is not a sign of weakness. The goal is |
| 1. Establish the project's business requirements and | | | | to get the project delivered. You will be judged on |
| success criteria | | | | successful project delivery not whether you heroically |
| Understand which stakeholders are driving which | | | | achieved it on your own at great personal sacrifice. |
| business requirements, and understand the relative | | | | 6. Communicate regularly in both written and verbal |
| importance of each requirement. Understanding the | | | | form |
| underlying business requirements will help steer the | | | | Many people rely on email simply out of habit, rather |
| project to success which, in the end, is all about | | | | than picking up the phone. Verbal, and face to face, |
| delivering business value. | | | | communication is often clearer and more efficient. |
| Business requirements should be expressed in terms | | | | Email should be used to confirm agreements and |
| of SMART business goals. SMART goals are usually | | | | communicate decisions, but it should not be used as a |
| defined as being: | | | | discussion forum; doing so creates a large amount of |
| - Specific | | | | information-poor correspondence which quickly |
| - Measurable | | | | becomes hard to manage. |
| - Achievable | | | | Written communication is essential to record business |
| - Relevant | | | | and functional requirements, implementation designs, |
| - Time-bound | | | | choices and decisions, and issues and risks. Written |
| While business requirements need to be more specific | | | | information should be concise; more is not always |
| they may be based on one or several of the following: | | | | better. |
| - Ensuring customers can get consistent and accurate | | | | Documents should go through a formal review and |
| information, quickly and easily. | | | | sign-off process. The process itself improves |
| - Reducing service delivery or production costs. | | | | communication and reduces risk, as well as providing a |
| - Improving customer retention by improving product | | | | formal record. |
| quality. | | | | Communicating risks and issues is an important part of |
| - Improving customer retention by improving customer | | | | project communication. However repetitive review of |
| service. | | | | long, growing lists can be a sign of an unhealthy |
| - Ensuring regulatory compliance; for example | | | | project; not because the issues and risks arise but |
| protecting confidential information from misuse or theft. | | | | because they are not being dealt with. Action should |
| For large projects, which may run for 12 months or | | | | be taken promptly to mitigate risks and resolve issues; |
| more, business requirements should be reviewed at | | | | once mitigated or resolved they should not need to |
| appropriate intervals to ensure that the project is | | | | remain on the list. Items which remain on a risk or issue |
| keeping up with any changes in priority, emphasis or | | | | list for a long period should stick out like a sore thumb. |
| perception, and that judgements regarding business | | | | 7. Don't assume that everything will go well, because it |
| benefit and return on investment are revalidated. | | | | won't |
| 2. Define, and be able to justify, all the functional | | | | Everything will not go well, so don't assume that it will, |
| requirements | | | | particularly in your planning. Assumptions will be proven |
| Be clear how each requirement will contribute to | | | | false, software will have bugs, people will get sick or |
| reaching the business goals, and contribute to providing | | | | leave, unforeseen changes will be required. |
| a return on investment for the project. | | | | Because of this, take the following steps: |
| Functional requirements should express what the | | | | - Actively plan to challenge and dispose of every |
| system will actually do, but not how it will be | | | | assumption as early as possible |
| implemented. While implementation design logically | | | | - Review lists of known bugs or issues which can be |
| comes later, implementation cost is a consideration to | | | | obtained from relevant suppliers |
| ensure that the project will deliver a return on | | | | - Plan to exercise software features you plan to use |
| investment. | | | | to flush out any issues which may impact your project. |
| If the estimated implementation cost of a specific | | | | (This can also serve as a self learning / training |
| functional requirement isn't going to provide a return on | | | | opportunity.) |
| investment then an alternative needs to be found | | | | - You should be aware of the maintenance policies |
| through a different combination or selection of | | | | and release plans of the software vendors. This will |
| technologies and/or manual processes. | | | | allow you to determine whether any bugs found could |
| Functional requirements should be clear and distinct | | | | be fixed within the timescales required, and what |
| such that each can be prioritised, tracked and | | | | action you may need to take if they cannot be |
| measured and, where appropriate, responsibility | | | | addressed. |
| delegated. | | | | 8. Define your quality assurance and testing approach |
| 3. Understand the business-as-usual working | | | | early |
| environment | | | | The process, timescales and resources for quality |
| For any software solution the business environment | | | | assurance and testing should be agreed well in |
| includes: | | | | advance. This may be agreed during the initial planning |
| - People and Organisational Units | | | | stages, but should be reviewed after the functional and |
| - Policies, Processes and Procedures | | | | implementation design phases. Leaving it until the |
| - Technology | | | | implementation phase is complete is way too late! |
| A successful project requires an understanding of how | | | | In order to keep to committed milestone dates, it is not |
| the new or updated solution will work with all of the | | | | uncommon to reduce the time available for testing, and |
| above. For a software project, technology (hardware, | | | | in the process incur additional quality risks. Doing so |
| software, networks etc.) is hard to ignore, and the | | | | rarely results in reducing the testing and quality |
| solution will usually be made to function; but other | | | | improvement effort, it merely defers it until your users |
| considerations can be equally important for it to really | | | | are already experiencing the quality issues the original |
| deliver on its business goals. | | | | planned effort intended to avoid. This is usually |
| A new solution can fail to deliver benefit if: | | | | avoidable; but if it is to happen then make sure that the |
| - Users don't know how or when to use it. | | | | resources remain available after launch to handle it. |
| - Users don't use it because they don't like it, or trust it. | | | | 9. Take great care in planning system changes to |
| - Support staff don't know how to support the | | | | minimise the risk of disruption |
| solution's users. | | | | The final steps to rollout out a new or revised system |
| - Operations staff don't know how to maintain it and | | | | should go ahead without issue, with sufficient |
| ensure it stays working. | | | | preparation, but it is necessary to be prepared for the |
| Software solutions need to operate within an existing | | | | unexpected. As we cannot know what the |
| technology landscape. Compatibility, interoperability and | | | | unexpected might be there are just two things we |
| security issues need to be considered. Consideration | | | | should do. |
| also needs to be given to the way this landscape is | | | | |
| expected to change to ensure the solution will deliver | | | | 1. Make sure everyone involved in the project is aware |
| lasting benefit. | | | | when changes are going to be made, and that they |
| 4. Understand the implementation design options | | | | can be made available to resolve issues and/or |
| available | | | | answer questions promptly if necessary. |
| Functional requirements can invariably be implemented | | | | 2. Make sure all the systems involved can be restored |
| in many ways, using different combinations of | | | | to their original state should any significant failures arise |
| platforms, products, configurations, and customisations. | | | | which cannot be resolved quickly - this includes having |
| Often these choices are rightly limited by previous | | | | the right people with right authority available to restore |
| decisions which have already been made. Companies | | | | the systems; being able to restore a system in theory |
| have preferred suppliers, existing license agreements, | | | | is no good if you cannot do so in practice. |
| and existing in-house skill sets. These preferences | | | | 10. Plan for post launch activities |
| improve predictability and reduce risk by ensuring that | | | | Once a system has been launched it should become |
| the required experience is available. | | | | part of the normal operations of the company. |
| Using completely new technologies can have benefits | | | | However it is likely that: |
| which can lead to competitive advantages, but doing | | | | - There are some improvements or capabilities which |
| so should be done with caution. New technologies | | | | didn't make the first cut. |
| should be thoroughly evaluated to determine their | | | | - Performance measurements need to be made to |
| suitability, reliability and cost effectiveness. | | | | confirm that it is delivering all the benefits it was |
| 5. Use all the available experience | | | | originally intended to deliver. |
| Success requires teamwork. Identify and engage with | | | | - During early activities, as the system "beds down", |
| the people who will be responsible for bring about all | | | | lessons will be learned and observations made, which |
| the necessary changes to the systems, processes | | | | could lead to further improvements or optimisations. |
| and procedures impacted by the project. | | | | The above items are actually more than likely, they are |
| Engaging with these people early is critical to success | | | | a certainty. So it is better to have some time already in |
| as: | | | | the plan and budget to allow for them. While such |
| - They have real and relevant experience about what | | | | items can be budgeted for later, doing so will likely |
| needs to change, how to make change, how long it | | | | cause delay. Further, if the launch is part of a |
| might take, and what issues you might face; and they | | | | multi-phased project or program, these items will have |
| can therefore help you plan effectively. | | | | a knock on effect, causing further delay downstream. |