|
|
|
|
| Best-Practice Guides
|
|
|
|
|
|
Business systems project framework
|
|
|
|
|
|
This template provides a graphical view of every action in an IT project – the key deliverables, who should run each project element and who should sign every element off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guide to project planning
|
|
|
|
|
|
The project plan is the backbone of all project management. It defines what is to be done, how it is to be done and
when it is to be done. The project plan identifies responsibilities for providing the specific products that will ultimately
deliver real business benefit.
A poorly planned project may be delivered late and cause frustration to everybody involved. Needless to say, a poorly
managed project will probably be more expensive to deliver than a well-planned one.
1. Project plan overview.
A detailed project plan will add gravitas and credibility to all decisions made during the life of the project.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guide to investment appraisal
|
|
|
|
|
|
Many businesses have numerous project requests which need to be prioritised and assessed, and every business
wants to quantify the financial benefits of a project before proceeding.
There are a number of ways of evaluating projects and this document outlines the most common methods – using
capital and ongoing project costs and comparing them with projected business benefits.
As with any model, the results are only as good as the quality of data provided in the first place. It is important that all
project costs (internal as well as external) are captured and that the business benefit numbers are supported by the
associated managers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Business requirements document
|
|
|
|
|
|
This is a key document for the whole project. It defines the most important measure against which everything else must
be benchmarked – business value.
The Business Requirements Document defines the business need and the commercial opportunity. Before considering
technology or other solutions, it is essential that business managers are clear about the business outcome they want to
achieve and why.
The problem or opportunity should be described in business terms and should be clear enough to enable someone with
no previous knowledge of the business to understand the context of the requirement.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Indemnities in IT/outsourcing contracts: Barlow Lyde & Gilbert
|
|
|
|
|
|
In most forms of technology or outsourced services agreement, there will be a number of provisions which provide for
liability to be imposed on an ‘indemnity’ basis. Some seem to pass by without substantial debate or negotiation, whilst
others can be amongst the hardest-fought provisions in the entire contracting process. However, there seems to be
limited uniformity in either the extent of the use of such provisions, or even on their desired or actual impact. This
document accordingly looks at the various contexts in which indemnities appear in IT and outsourcing contracts, and
the ways in which they are likely to be interpreted by the courts, as well as some practical drafting issues which often
arise.
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|