Show Menu

Digital Project Handbook Cheat Sheet by

System develo­pment life cycle

Not part of the project
Justify the project
Short phase
Checks that a problem or opport­unity really exists
Decides whether the proposed change appears to be desirable,
Identi­fic­ation of the business case
Assesses whether the proposed develo­pment is practical in terms of the balance of costs and benefits the technical requir­ements and the organi­sat­ion’s inform­ation system objectives
Output is a feasib­ility 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
Requir­ements elicit­ation and analysis
Defines the requir­ements of the new system in detail
May involve:
interv­iewing users
examining docume­ntation describing the current operations
analysing operat­ional records created by the current system
observ­ation of work practices
joint applic­ation develo­pment (JAD) sessions – stakeh­olders and business analysts in intensive sessions identify and agree detailed requir­ements;
questi­onnaire surveys
Mock ups and prototypes
Output is a requir­ements statement
Translates the business specif­ication for the automated parts of the system into a design specif­ication of the computer processes and data stores that will be needed
Elements to be designed include: inputs, outputs, proces­sing, data and inform­ation structures
Logical design: identi­fic­ation of the inputs, outputs, business rules and inform­ation that the system will process
Physical design: Concerned with the actual appearance of the input and output screens and the printed reports
Objective of designing, coding and testing software and ensuring effective integr­ation between different software components
Produce procedure manuals
New hardware acquired
Requir­ements statement will be re-exa­mined to ensure that it is being followed to the letter
Acceptance testing
User testing
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 respon­sib­ility for mainte­nance and support to a permanent team
Closing down accounts relating to the project
Project manager writing a lessons learnt report
Releasing and re-all­ocating project resources
Arranging publicity to tell the outside world about the project’s success
Review and mainte­nance
Post-i­mpl­eme­ntation review should be carried out by a business analyst who was not involved in the original project

The project plan

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, procur­ement, human resources, commun­ication and quality.
Control document
Project initiation document
Schedule planning
Cost planning
Resource planning
Commun­ication planning
Quality planning

Resource planning

Project plan needs to account for various types of resources, including people, equipment and facilities
Respon­sib­ility assignment matrix (RAM): simple matrix showing indivi­duals associated with the project on one axis and the activities for which they are respon­sible on the other.

Quality planning

To develop a system which meets all users’ functional and system perfor­mance requir­ements documented during analysis, a carefully considered quality plan is needed
Quality criteria can be applied both to project delive­rables and to the processes by which the delive­rables 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 feasib­ility study)
Showing value of benefits greater than costs
Consider business concerns
Consider technical diffic­ulties of the project
Project attributes
Defined start point, which is when:
Becomes an undert­aking instead of just idea
Obtains business backing and a project sponsor – financial backer within the organi­sation
A commitment is made to provide the necessary resources
Respon­sib­ilities are defined
Initial plans are produced
Drive team actions towards common goal
Stated and understood at project start
Clear and unambi­guous
Set of outputs or delive­rables
Set end date
Set max budget
A unique purpose
Benefits which are measur­eable and greater than costs

Successful projects

Enable the stated objectives to be achieved
Delivered on time and within budget
Deliver a system that performs to agreed specif­ica­tions
Satisfy the project sponsor and other interested parties (stake­hol­ders)

Final judges

Project sponsor and the users
Being sensitive to their needs as important as sticking to the letter of a contract

Types of requir­ements


Iterative model

Waterfall model

Project initiation document

Starts with an intro with project backgr­ound, document’s purpose, business justif­ication for the project
Goals, objectives and delive­rables
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 inform­ation will be recorded
How packages of work will be signed off and reviews conducted
The people respon­sible for recording and assessing the impact of any changes
The people respon­sible for author­ising different levels of change to goals, object­ives, delive­rables, cost or completion date
Risks and assump­tions section
Commun­ication plan

Post implem­ent­ation review

Usually scheduled 6 to 12 months after sign-off
Review the implem­ented system in terms of its contri­bution to business objectives
Whether the business and system requir­ements have been met
Cost and benefit perfor­mance
Operat­ional perfor­mance
Controls, audita­bility, security and contin­gency
Ease of use
Output: post-i­mpl­eme­ntation review report

SMART mnemonic for good objectives

Specific, Measurable, Achievable, Resourc­e-c­ons­trained and Time-co­nst­rained

Three specif­ica­tions aka ‘iron triangle’

Specified cost
Specified time
Meet a specified business requir­ement.
These three specif­ica­tions are closely linked and any change to one will affect the others.
These form the scope

Projects should have

Clearly defined respon­sib­ilities
Clear objectives and scope. If you don’t have these you’ll have lots of problems in the future
Change procedures
Reporting and commun­ication

Elements of project management

Planning and estimating
Monitoring and control
Issue management
Change control
Risk management
Project assurance
Project organi­sation
Business change management

Develo­pment process models

IT develo­pment need a well-d­efined, repeatable and predic­table system develo­pment life cycle
Waterfall method
Basic phased model of a develo­pment cycle
One-shot or once-t­hrough 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 requir­ements have been clearly defined and agreed, most projects don’t at beginning
Works best where there are few changes
Requires tons of docume­ntation
Reduce bureau­cratic obstacles by encour­aging intense, informal, commun­ication between project partic­ipants
Breaks project into increments called sprints
Activities small steps which are listed in a backlog
Increm­ental and iterative
Develop in fragments
Global requir­ements are defined and an overall archit­ecture designed
Product is developed in increm­ents. After each increment is designed, developed and tested, it is system tested and then becomes operat­ional, so that users get their new system in instal­ments
Works best when reqs are well known
Iterative model
Suited to situations in which the requir­ements are not clearly understood and where there is a need to begin develo­pment quickly
Customer can make sugges­tions for the next iteration
Risk associated with this model is not knowing when to stop iterating

Increm­ental model

Schedule planning

Definition of requir­ements that is agreed and unambi­guous
Careful breakdown of work
Schedule when activities will start and end and the resources

Cost planning

If the costs of the project exceed the value of its benefits, the project becomes unecon­omic. It is also possible for an organi­sation to simply run out of money for a project.
Estimate quantities and costs, set budgets

Commun­ication planning

Flows of commun­ication during the project
How commun­ication tools will be used
What meetings will be held with what attendees, and at what times

Implem­ent­ation strategies

Get user input and make a recomm­end­ation on the best type to the steering committee
Direct changeover
The old system is discarded and immedi­ately replaced by the new one
Relatively inexpe­nsive
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
Contin­uation of testing
Low risk
Phased take-on
Breaks the system into components that will be introduced in sequence
Low risk
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 compan­y-wide, but compan­y-wide deployment of the entire system is conseq­uently delayed.


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Microsoft Project Cheat Sheet
          System improvements Cheat Sheet
          ISTQB Test Automation Engineering Cheat Sheet

          More Cheat Sheets by NatalieMoore