1. Think in terms of 'problem scope' and 'solution scope' and be prepared to analyze the end-to-end processes and then select those areas with the greatest return while building in hooks for the future.

2. Generate process-based business requirements in conjunction with the business, identifying how the organization wants to do business, compete and make money in the future. You should be able to take out 50% of the current process steps along the way.

   Generate process, information and logic requirements (which allows systems to be selected and configured) as well as desired business outcomes and change plans to ensure the business can use the systems and realize the benefits.

   Your requirements need all of these elements to be present.

3. Focus the whole project on the achievement of 'desired business outcomes' — the end states the business wants to achieve. These outcomes drive the benefits — no outcomes, no benefits. But work with the business to ensure these are the right outcomes!

4. Select the software based on both its appropriate foundations or sources, and its fit to your process-based requirements. It is not a question of whether the software has the right functions and features so much as does it work with the same dynamics as your business?

5. Develop a compelling business case that clearly spells out the rationale and value proposition for the project, maximizes the project's value and sets out the measures of success. This should now be seen as the contract between the Sponsor and the organization, as well as the defining the overall value to be delivered.

6. Educate, support and coach your project governance team to be active contributors to your project's success. Make sure they see that it is their business outcomes and benefits that are being targeted and, therefore, they have a very real vested interest in the project's business success.

7. Plan from the business outcomes and benefits backwards to identify all of the activities required and avoid too much activities at the last minute. This will also ensure the tasks required to deliver each benefit are known up front and can be allocated to the business in due course to be actioned.

8. Strive to move the estimating step to the point when the requirements and solution are known so that the estimates are likely to be realistic. Use standards where available and proven to be reliable, but beware of over-estimations that increase time and cost but not quality or value.

9. Put organizational change as the central plank of your project delivery process — you're here to deliver change/improvements and everything else is just supporting this goal. Don't think of the system as the core of your project.

10. Support the continuous tracking and measurement of benefits, both during and after the end of the project so that the benefits are realized and are seen to be maximized. This is, after all, one of the primary business measures of success.

11. Clearly, as soon as possible, define where the project stops and the business takes over — the handover point. These points need to be measurable so there is no confusion or debate, and must allow the business to go on and realize the remaining outcomes and benefits.

12. Harness the resources and services of the PMO to reduce your workload and avoid problems caused by other projects. They should be seen as a resource for you.

Simple really, isn't it?

To read Jed's last column, Why Projects Fail, Part 13: The Impact of the 12 Reasons on Project Success , click here

Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialized project management and project governance Web site www.project-sponsor.com