|
Initiation
|
|
|
Not part of the project
|
|
|
Justify the project
|
|
|
Short phase
|
|
|
Checks that a problem or opportunity really exists
|
|
|
Decides whether the proposed change appears to be desirable,
|
|
|
Identification of the business case
|
|
|
Assesses whether the proposed development is practical in terms of the balance of costs and benefits the technical requirements and the organisation’s information system objectives
|
|
|
Output is a feasibility report
|
|
|
Project set-up
|
|
|
Decide to go ahead
|
|
|
Steering committee set up
|
|
|
PM appointed
|
|
|
Project steam initially set up to start
|
|
|
Detailed planning undertaken
|
|
|
Important decisions are made
|
|
|
Requirements elicitation and analysis
|
|
|
Defines the requirements of the new system in detail
|
|
|
May involve:
|
|
|
-
|
interviewing users
|
|
-
|
examining documentation describing the current operations
|
|
-
|
analysing operational records created by the current system
|
|
-
|
observation of work practices
|
|
-
|
joint application development (JAD) sessions – stakeholders and business analysts in intensive sessions identify and agree detailed requirements;
|
|
-
|
questionnaire surveys
|
|
-
|
Mock ups and prototypes
|
|
Output is a requirements statement
|
|
|
Design
|
|
|
Translates the business specification for the automated parts of the system into a design specification of the computer processes and data stores that will be needed
|
|
|
Elements to be designed include: inputs, outputs, processing, data and information structures
|
|
|
Logical design: identification of the inputs, outputs, business rules and information that the system will process
|
|
|
Physical design: Concerned with the actual appearance of the input and output screens and the printed reports
|
|
|
Construction
|
|
|
Objective of designing, coding and testing software and ensuring effective integration between different software components
|
|
|
Produce procedure manuals
|
|
|
New hardware acquired
|
|
|
Requirements statement will be re-examined to ensure that it is being followed to the letter
|
|
|
Acceptance testing
|
|
|
User testing
|
|
|
Implementation/installation
|
|
|
Hardware that has been purchased is delivered and installed.
|
|
|
Software is installed
|
|
|
Users trained
|
|
|
Initial content of databases set up
|
|
|
Project closure
|
|
|
Sign-off of acceptance documents
|
|
|
Handing over responsibility for maintenance and support to a permanent team
|
|
|
Closing down accounts relating to the project
|
|
|
Project manager writing a lessons learnt report
|
|
|
Releasing and re-allocating project resources
|
|
|
Arranging publicity to tell the outside world about the project’s success
|
|
|
Review and maintenance
|
|
|
Post-implementation review should be carried out by a business analyst who was not involved in the original project
|
|
|
Part of set up phase
|
|
|
Consists of several different types of documents, including activity networks and Gantt charts
|
|
|
Not cast in stone
|
|
|
Defines the project’s scope, schedule and cost, as well as the supporting processes related to risk, procurement, human resources, communication and quality.
|
|
|
Control document
|
|
|
Includes
|
|
|
-
|
Project initiation document
|
|
-
|
Schedule planning
|
|
-
|
Cost planning
|
|
-
|
Resource planning
|
|
-
|
Communication planning
|
|
-
|
Quality planning
|
|
Project plan needs to account for various types of resources, including people, equipment and facilities
|
|
|
Responsibility assignment matrix (RAM): simple matrix showing individuals associated with the project on one axis and the activities for which they are responsible on the other.
|
|
To develop a system which meets all users’ functional and system performance requirements documented during analysis, a carefully considered quality plan is needed
|
|
|
Quality criteria can be applied both to project deliverables and to the processes by which the deliverables are created
|
|
|
Don’t let quality get overruled by deadlines and budget cuts. Emphasise throughout entire project
|
|
A group of related activities carried out to achieve a specific objective
|
|
|
Start from an idea about a desirable product or change
|
|
|
Business case (aka feasibility study)
|
|
|
-
|
Showing value of benefits greater than costs
|
|
-
|
Consider business concerns
|
|
-
|
Consider technical difficulties of the project
|
|
Project attributes
|
|
|
Defined start point, which is when:
|
|
|
-
|
Becomes an undertaking instead of just idea
|
|
-
|
Obtains business backing and a project sponsor – financial backer within the organisation
|
|
-
|
A commitment is made to provide the necessary resources
|
|
-
|
Responsibilities are defined
|
|
-
|
Initial plans are produced
|
|
Objectives
|
|
|
-
|
Drive team actions towards common goal
|
|
-
|
Stated and understood at project start
|
|
-
|
Clear and unambiguous
|
|
Set of outputs or deliverables
|
|
|
Set end date
|
|
|
Set max budget
|
|
|
A unique purpose
|
|
|
Benefits which are measureable and greater than costs
|
|
|
Enable the stated objectives to be achieved
|
|
|
Delivered on time and within budget
|
|
|
Deliver a system that performs to agreed specifications
|
|
|
Satisfy the project sponsor and other interested parties (stakeholders)
|
|
Project sponsor and the users
|
|
|
Being sensitive to their needs as important as sticking to the letter of a contract
|
|
Functional
|
|
|
Cost
|
|
|
Quality
|
|
|
Deadline
|
|
|
Legal
|
|
Starts with an intro with project background, document’s purpose, business justification for the project
|
|
|
Goals, objectives and deliverables
|
|
|
Project org chart
|
|
|
Project structure section
|
|
|
List of project milestones
|
|
|
Success and completion criteria
|
|
|
Management control section
|
|
|
-
|
Reports timing and who gets them
|
|
-
|
How plan to be produced and maintained
|
|
-
|
How the information will be recorded
|
|
-
|
How packages of work will be signed off and reviews conducted
|
|
-
|
The people responsible for recording and assessing the impact of any changes
|
|
-
|
The people responsible for authorising different levels of change to goals, objectives, deliverables, cost or completion date
|
|
Risks and assumptions section
|
|
|
Communication plan
|
|
|
Usually scheduled 6 to 12 months after sign-off
|
|
|
Review the implemented system in terms of its contribution to business objectives
|
|
|
Considers
|
|
|
-
|
Whether the business and system requirements have been met
|
|
-
|
Cost and benefit performance
|
|
-
|
Operational performance
|
|
-
|
Controls, auditability, security and contingency
|
|
-
|
Ease of use
|
|
Output: post-implementation review report
|
|
|
Specific, Measurable, Achievable, Resource-constrained and Time-constrained
|
|
Specified cost
|
|
|
Specified time
|
|
|
Meet a specified business requirement.
|
|
|
These three specifications are closely linked and any change to one will affect the others.
|
|
Clearly defined responsibilities
|
|
|
Clear objectives and scope. If you don’t have these you’ll have lots of problems in the future
|
|
|
Control
|
|
|
Change procedures
|
|
|
Reporting and communication
|
|
Planning and estimating
|
|
|
Monitoring and control
|
|
|
Issue management
|
|
|
Change control
|
|
|
Risk management
|
|
|
Project assurance
|
|
|
Project organisation
|
|
|
Business change management
|
|
IT development need a well-defined, repeatable and predictable system development life cycle
|
|
|
Waterfall method
|
|
|
Basic phased model of a development cycle
|
|
|
One-shot or once-through approach
|
|
|
Each phase cascades into the next
|
|
|
Assumes takes done in a strict sequence
|
|
|
Can loop back but expensive and lots of replanning required
|
|
|
Best used on projects where requirements have been clearly defined and agreed, most projects don’t at beginning
|
|
|
Works best where there are few changes
|
|
|
Requires tons of documentation
|
|
|
Agile
|
|
|
Reduce bureaucratic obstacles by encouraging intense, informal, communication between project participants
|
|
|
Scrum
|
|
|
-
|
Breaks project into increments called sprints
|
|
-
|
Activities small steps which are listed in a backlog
|
|
Incremental and iterative
|
|
|
Incremental
|
|
|
-
|
Develop in fragments
|
|
-
|
Global requirements are defined and an overall architecture designed
|
|
-
|
Product is developed in increments. After each increment is designed, developed and tested, it is system tested and then becomes operational, so that users get their new system in instalments
|
|
-
|
Works best when reqs are well known
|
|
Iterative model
|
|
|
-
|
Suited to situations in which the requirements are not clearly understood and where there is a need to begin development quickly
|
|
-
|
Prototypes
|
|
-
|
Customer can make suggestions for the next iteration
|
|
-
|
Risk associated with this model is not knowing when to stop iterating
|
|
Definition of requirements that is agreed and unambiguous
|
|
|
Careful breakdown of work
|
|
|
Schedule when activities will start and end and the resources
|
|
If the costs of the project exceed the value of its benefits, the project becomes uneconomic. It is also possible for an organisation to simply run out of money for a project.
|
|
|
Estimate quantities and costs, set budgets
|
|
Flows of communication during the project
|
|
|
How communication tools will be used
|
|
|
What meetings will be held with what attendees, and at what times
|
|
Get user input and make a recommendation on the best type to the steering committee
|
|
|
Direct changeover
|
|
|
The old system is discarded and immediately replaced by the new one
|
|
|
Risky
|
|
|
Relatively inexpensive
|
|
|
Need great testing
|
|
|
More risky for higher complexity systems
|
|
|
Parallel running
|
|
|
Running the old and new systems together for a period of time using the same inputs and comparing the related outputs
|
|
|
Continuation of testing
|
|
|
Safe
|
|
|
Low risk
|
|
|
Expensive
|
|
|
Phased take-on
|
|
|
Breaks the system into components that will be introduced in sequence
|
|
|
Low risk
|
|
|
Slow
|
|
|
Allow users to learn one system component at a time
|
|
|
Pilot changeover
|
|
|
Entire new system is introduced to just one business unit or location
|
|
|
Problems can be addressed and fixed before the system is introduced company-wide, but company-wide deployment of the entire system is consequently delayed.
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
