A Checklist For Successful Software Projects

Successful Software Projects Checklist
Confidentiality Statement
This Successful Software Projects Checklists along with all attachments hereto shall be considered
<company>’s Proprietary/Confidential Information
ProjectManagement.com Successful Software Projects Checklist
Using this Document - Business Benefits
"If you fail to plan, you plan to fail."
Managing software projects is difficult under the best circumstances. Unfortunately, many new project
managers receive virtually no job training. Half the battle is won though when you come prepared and
well-planned with a checklist of what contributes to software development success.
Use the following checklists (covering the general software development concerns, project planning,
start of project, project kickoff to end of project) as quick guidelines for ensuring a successful software
project. Keep these suggestions in mind during your next project, recognizing that none of them is a
silver bullet for your project management problems. Feel free to add to the list as you see fit.
General Concerns
Have you created and followed your Software Development Plan?
The Software Development Plan describes the project’s vision, defines the team structure, and
defines the development methods. The plan should include estimates, major milestones, and
other measures that will be used to track progress. The SDP should be a living document,
which is updated at the end of each major phase or stage.
Do you apply essential project management practices?

Many projects that get into trouble fail to apply proven project management disciplines like cost
estimation, project scheduling, resource planning, configuration management and proactive
risk management, and then wonder why their project is in constant turmoil. Duh.
Is everyone (project managers as well as upper management) realistic, and does

everyone have reasonable expectations for the project?
Some managers recognize the potential for negative impact on their project from potential
problem areas. However, they choose to see things the way they want to see them, assuming
that problems will work themselves out—even when all available evidence indicates otherwise.
Have you defined the requirements baseline and managed changes to it?
Stabilize requirements as early as possible. Keep a detailed list of potentially volatile

requirements or undefined requirements, and prioritize the list by estimated cost and schedule
impact. Try to resolve these items during architecture or, at latest, during detailed design.
Have you implemented effective software processes?

Many projects fail to implement effective software processes because their approach to
process application is unbalanced. Some apply minimal process and rely on staff expertise,
while others insist on rigorous global process conformance.
Do you have competent project management leadership?

Managing a software project requires gutsy individuals willing to confront challenges today to
avoid disaster tomorrow. Beware of these two types of problem managers: those with software
engineering and no management experience, and those with management and no software
engineering experience. Both types lack the necessary mix of both technical and managerial
©2017 ProjectManagement.com 2
know-how.
Do you make decisions in a timely fashion?

Some managers avoid making time-critical decisions until it is too late, even when faced with
overwhelming warning signs of impending problems.
Are you practicing proactive risk management?

Many projects claim to implement risk management, but few do so effectively. How well can
you contain your failures?
Have you determined the amount of documentation necessary for project success?
Different projects require different kinds of documentation support. Determine the amount and
kind of documentation required based on the project size, schedule, and expected lifetime of
the system.
Do you ensure that standards are not relaxed in order to cuts costs or shorten a
schedule?
Relaxing standards tends to introduce errors into the project, and optimum project cost and
schedule both depend on eliminating errors. Relaxing standards can also have a
demotivational effect. Most developers are quality oriented, and a relaxation of standards
sends the message that the customer or upper management doesn’t care about quality.
Have you avoided assuming that a schedule slip in the middle of a phase will be made
up later?
One common mistake is to assume that productivity will improve as the project progresses
from the beginning of a phase to the end. Productivity might improve slightly, but there isn’t
enough time within any particular phase to make up time.
Have you avoided setting unreasonable goals?
It is worse to set unreasonable goals than to set no goals at all. If the team doesn’t believe in
the goals, they will merely put in their time, punch the clock, and go home. If they are rushed,
they will make mistakes upstream that cost fortunes to correct downstream. Set reasonable,
moderately challenging goals, and the team will stretch to meet them without damaging project
efficiency.
When implementing changes, have you assessed their impacts and obtained approval
of the change board?
Estimate the impacts of each change—even important, small changes that the project can
absorb without rescheduling. The project needs a record of how it changed over time, in both
major and minor ways. Even if a particular change does not have a large impact, small
changes add up over time and will eventually cause cost and schedule overruns if not
controlled.
Are you celebrating achievements too early?
Pressures to deliver timely products often result in premature declarations of completion by

managers. Success cannot be declared until products have been completed with the built-in
contracted quality and reliability.
Requirements Management
Are the requirements sufficient, complete, uniquely identifiable, clearly and appropriately
prioritized?
Are there no internal contradictions among the requirements?
Does the set of requirements adequately address all appropriate exception and boundary
conditions?
Are the requirements feasible? (i.e., a solution to the set of requirements exist)
Can the requirements be implemented within known constraints?
Are all cross-references to other requirements correct?
Have all functional and non-functional requirements been considered?
Are all requirements testable/verifiable and traceable?
Project Plan Content
General
Is the background and context of the project described?
Is a summary of the project provided?
Are assumptions, constants, and dependencies identified?
Is the approach for the project outlined?
If appropriate, are external interfaces defined?
Deliverables
Are the deliverables on the project described?
Is the relevant information about each deliverable included? (e.g. dates, methods, locations,
etc.)
Risk and Asset Management

Are the top project risks enumerated?
Are the top project assets enumerated?
Communication
Are the communication channels and interfaces defined?
Project Organization
Is the organization of the project described?
Have the relevant roles and responsibilities been defined?
Project Lifecycle
Is the selection of a project lifecycle described and explained?
Is any tailoring done to the lifecycle described and explained?
Tracking and Control
Are the mechanisms by which the project will be tracked outlined?
Technical Process
Are the high-level technical processes that will be used on the project described? (e.g.
design tools, programming languages, etc.)
Estimate
Are one or more estimates for the project outlined?
Are the estimation techniques and confidence levels described?
Resource Management
Are the necessary resources identified?
Are any gaps between the needed and available resources identified?
Has the resource allocation necessary to obtain the project goals within the constraints
described?
Project Plan Usage
Development Team Have Input
Are key members of the development team involved in all aspects of the estimation process,
especially on how long it will take to develop the system? As project manager, your job is to
ensure that the development estimates are reasonable, adding time to cover risk that you
might see.
Person Responsible For Each Item Signs Off Estimate
Has the person who will be implementing each part of the system agreed to take responsibility
for implementing it in the time estimated? While not usually a formal sign off, it is important that
the developer have the confidence about the estimates they are expected to work to.
Project Manager Signs Off Each Estimate
Has the Project Manager agreed that each item is estimated realistically? Since PMs have
responsibility for bringing the project to completion in the time specified by the plan, it is
important that PMs have some degree of confidence in each item of the plan.
High Risk and High Value Items Brought Forward
Has the plan identified high risk and high value tasks and brings them as far forward as
possible? It makes sense to do the risky items first, since it gives you more time to fix problems
if things go wrong. Similarly, it makes sense to do items that add a lot of business value first,
since the project can then more quickly demonstrate to the customer that it is meeting their
needs.
Time Allocated For Standard Tasks
Does the plan allocate sensible amounts of time for Requirements, Design, Development, Test
and Deployment? Check that your project plan has time for all of them to avoid unnecessary
confusion and panic.
Deliveries Scheduled Every 2-3 Weeks
Does the project plan deliver to the client at regular intervals (2 to 3 weeks)? Projects with
many, regular deliveries are inherently simpler to control than one that produces nothing until
the very end. Each delivery becomes a concrete milestone that is visibly met or not met.
Regular deliveries also allow users to give constructive feedback sooner that they otherwise
would.
Assumptions and Dependencies Documented
Are all assumptions made and external dependencies specified in the plan explicitly
documented? Because plans are drawn up early on in the project lifecycle, there will be many
unknowns, and assumptions need to be made in order to produce a schedule, and so that the
plan can be modified appropriately should the assumption turn out to be false.
Development Activities Traceable to Requirements
Can every development activity be traced - perhaps via the design - to a business
requirement? Essentially, no matter how 'nice' a requirements is, it should not be done unless
there is a clear business benefit that is within the scope of the project.
Risks Addressed
Does the plan address risk in a comprehensive manner? The kinds of things that you should
be looking at in any project are: an effort made to identify the biggest risks to on-time, on-
budget delivery, the effect of the risk on the project, should the event occur, estimates of how
likely each risk is to occur, and an appropriate mitigation strategy for each risk.
Plan is Easily Understood
Is the plan presented in such a way that it can be understood by everybody who is expected to
use it? An effectively communicated plan is a great help to the project manager because it
allows individuals within the team to take more responsibility for keeping to the schedule.
Track against Plan
Is the project's progress is tracked against the plan? It is a good idea to track the project
weekly, so that the weekly project report includes an accurate picture of progress.
Plan Changes with Circumstances
Is the project plan revised as necessary in order to meet the project budget and timeframe?
While a good project manager will allow for minor perturbations in the plan, however when
something major occurs - such as missing the finish date of a critical task - the plan must be
changed to take this into account.
At Start of Project
Business Case Approved

Have the business case and project scope been approved by senior management? With a
signed, approved business case you are assured that senior management are at least aware
of the project and what it has set out to accomplish.
Project Supervision (e.g., Steering Committee) In Place

Is there a formal structure in place for senior management to review project progress? At each
milestone, the steering committee decides whether the project should continue.
Detailed Requirements Available

Are the project requirements available and do they describe the projects expected outputs
(product) in detail? Quite often, producing requirements is the first step in the project. Ensure
that the project has the means to determine these requirements.
Development Environment Checklist Completed

Have you completed the Software Development Environment Checklist? This checks that an
appropriate software development environment is available to the project including compilers,
editors, debuggers, build system and configuration management system.
Testing Processes Defined

Are the testing processes required by the project defined and agreed with all stakeholders?
Ensure that all stakeholders understand and agree: what testing of the project products will
take place, the responsibilities of each stakeholder in the testing processes (especially where
the client or user department needs to provide people to do the testing), and the criteria that
will be used to accept the project products.
Project Kickoff: Team Members Assigned

Have all required team members been assigned to the project? It is important that
management is aware exactly who is working on the project and for what percentage of their
time.
Team Members Aware Of Their Project Role(s)

Does each team member know their role on the project, and the extent of their authority and
responsibility? For larger projects, where a more rigid structure is desirable, organization
charts are useful for clarifying roles.
Team Members Aware Of Their Project Role(s)

Does each team member know their role on the project, and the extent of their authority and
responsibility? For larger projects, where a more rigid structure is desirable, organization
charts are useful for clarifying roles.
At Project Kickoff
Project Kick-off Meeting Held

Has a meeting has been held to kick-off the project? This involves bringing the team together,
presenting the scope of the project and introducing individuals who will be filling roles in the
project. At all these meetings the format is the same: introduce the project, discuss its current
status and how the individuals in the room will contribute to the project goal.
Weekly Checklist: Progress checked against plan.

Is it already known how the project is progressing against the schedule? To bring a project to
an on-time, on-budget, everybody-happy completion you must ensure that at all times you
know how the project is progressing and what is causing any slippages. The best way to
gather this information is to actually ask, face to face - you are much more likely to get a true
picture of how tasks are progressing.
Team members aware of their tasks for the coming week

Do your team members know which task(s) they have been assigned to, when those tasks are
to be completed, and the dependencies for and on those tasks? Project team members are
thoroughly annoyed if they do not know what they are expected to do, or when is should be
finished. They are also annoyed when they are told to do something that they know they
cannot, and are not given an opportunity to voice their opinion. Avoid this justified annoyance.
Known Outages Accounted For

Have events that will take team member's time away from the project been allowed for in the
project plan? From time to time, there will be 'outages' in a project that can be planned for
(e.g., holidays, training, monthly division meetings and server upgrades). While some of these
will be known about while the project is being planned, others will crop up over time, and need
to be planned for.
Requirements Change Procedures Followed

Are new requirements reviewed, approved and planned for, before development begins? Many
projects suffer from users, business analysts and even technical architects wandering from
developer to developer and inserting "good ideas" into the project. While this is done with the
best of intentions, it has an impact on the schedule and must be controlled.
Team Morale is High

Is the team working together to achieve the project goals? Is there a 'good feeling' to the
project? Aside from the quality of life considerations, a happy team is the basis of a productive
team. By 'happy' we don't mean constantly joking around, rather we mean that individuals are
content to be working in the team and motivated to achieve the project goals. Such a team will
have a 'good feel' to it.
Correct Skills
Do the team members have skills appropriate to the tasks they have been assigned? While it is
not always possible, team members should have the skills to complete their tasks in a
professional manner. If this is not the case, remedial action needs to be taken: a training
course taken, a mentor assigned or more time allocated to the task.
Shares Knowledge and Skills

Does the team share knowledge and skills freely? Do team members have special tasks that
they keep to themselves? This is partly, an outcome of good team dynamics - if the team
respect one another and are comfortable working together working towards the completion of
the project, they will tend to share their skills and knowledge with one another.
Building Consensus
Is the team developing a consensus on procedures and standard for everyday tasks? A further
consequence of good team work is that standard ways of doing common tasks will emerge.
This is a good thing since it leads to standard, repeatable processes.
Work "Regular" Hours

Is there anybody working long hours for extended periods of time? Every project will have
times when extra effort is required, such as when a deadline is near. However, it is important
that work does not consume team member's lives. Not only is too much work bad for people's
health, eventually they get sick of it and burn out or quit.
Troubled Relationships Identified

Have inter-personal problems amongst the team members been noted and positive steps
taken to ensure it does not jeopardize the project? Personality clashes and general
disharmony are major time wasters, and can usually be traced back to a lack of respect
amongst team members for one another.
At End of Project
Deployment Plan Complete

Is there a written, detailed plan for deployment? This plan should include dates and times for
all elements of deployment including: final acceptance testing and roll out to production
hardware.
Users Have Sufficient Training

Have users of the new or improved system been equipped to use it? Training is often forgotten
until far too late, it is important that users of your system will have all of the training and
support they need to effectively use the new system.
Post Project Review (PPR)
Has the Post Project Review identified areas where the organization can improve its
performance on subsequent project? The timing of the PPR can be difficult, especially in large
projects that need to 'wind-down' over a long period. If necessary, schedule a separate review
for each group within the team: management, business analysts, developers, testers and so
on.
PPR Covered Trouble Spots

Did the Post Project Review agenda cover all areas where the project had already been
identified as lacking? When setting the agenda for the PPR, consider all of the comments that
have been made throughout the project about things that were lacking and feed it into the
review.
PPR Followed Up
Are action items from the Post Project Review followed up by the organization? Ensure that the
PPR was not in vain by communicating the results of the PPR widely. People working on other
projects will then be able to use the experiences summarized in the PPR when preparing to do
work on their own projects.
Are the source codes and documentation set stored in permanent form?
The project source code and documentation - requirements, design, testing and so forth - is
typically a deliverable expected by the customer. Even for internal projects, it is a good idea to
make a permanent backup of all the hard work done by project team members for future
reference. Allocate a set of special backup tapes to make multiple copies of the project source
code, or, better still, cut three or four CD-ROMs.
Has enough information been provided for Project Restart?

Ensure that enough information is available that a new project team could develop extensions
to the project product with minimal interruption. The importance of this item will vary greatly. If
the product of this project will continue to be developed by the same team, then it may not be
necessary to produce extra documentation at all - the knowledge will be carried forward to
new projects by the team.
Crosscheck
Ask yourself the following questions:
 Have you chosen the appropriate development lifecycle process to the project at hand?
 Has your development team understood what requirements (functional and non-functional)
needed to be built?
 Have you chosen the appropriate architecture for your application?

 Have you verified if your applications are either over-designed or under-designed?
 Have you setup standard best practices (e.g., continuous integration, daily build and test) in
construction of the code?
 Have you established review mechanisms for any artifact from the development process,
including plans, requirements, architecture, design, code, and test cases?
 Is testing an integral part of your software development and done proactively—meaning that
test cases are planned before coding starts, and test cases are developed while the
application is being designed and coded?
 Are you aware of the state of all artifacts that make up your system or project, managing the
state of those artifacts, and releasing distinct versions (configurations) of a system?
 Have you established quality priorities and release criteria for the project so that a plan is
constructed to help the team achieve quality software?
 Have you planned for deployment and used a deployment checklist?
 Have you setup a system operations and support to respond and resolve possible user
problems?
 Have you applied lessons learned from previous projects?
 Have you measured your development process against an industry standard chosen by your
company?

A Checklist For Successful Software Projects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Checklist For Successful Software Projects

Uploaded by

Copyright:

Available Formats

Successful Software Projects Checklist

Using this Document - Business Benefits

"If you fail to plan, you plan to fail."

Have you created and followed your Software Development Plan?

Do you apply essential project management practices?

Is everyone (project managers as well as upper management) realistic, and does

Stabilize requirements as early as possible. Keep a detailed list of potentially volatile

Have you implemented effective software processes?

Do you have competent project management leadership?

Do you make decisions in a timely fashion?

Are you practicing proactive risk management?

Have you avoided setting unreasonable goals?

Are you celebrating achievements too early?

Pressures to deliver timely products often result in premature declarations of completion by

Are there no internal contradictions among the requirements?

Can the requirements be implemented within known constraints?

Are all cross-references to other requirements correct?

Have all functional and non-functional requirements been considered?

Are all requirements testable/verifiable and traceable?

Project Plan Content

Risk and Asset Management

Tracking and Control

Are the mechanisms by which the project will be tracked outlined?

Project Plan Usage

Development Team Have Input

Person Responsible For Each Item Signs Off Estimate

Project Manager Signs Off Each Estimate

High Risk and High Value Items Brought Forward

Time Allocated For Standard Tasks

Deliveries Scheduled Every 2-3 Weeks

Assumptions and Dependencies Documented

Development Activities Traceable to Requirements

Plan is Easily Understood

Track against Plan

Plan Changes with Circumstances

Business Case Approved

Project Supervision (e.g., Steering Committee) In Place

Detailed Requirements Available

Development Environment Checklist Completed

Testing Processes Defined

Project Kickoff: Team Members Assigned

Team Members Aware Of Their Project Role(s)

Team Members Aware Of Their Project Role(s)

Project Kick-off Meeting Held

Weekly Checklist: Progress checked against plan.

Team members aware of their tasks for the coming week

Known Outages Accounted For

Requirements Change Procedures Followed

Team Morale is High

Shares Knowledge and Skills

Work "Regular" Hours

Troubled Relationships Identified

Deployment Plan Complete

Users Have Sufficient Training

Post Project Review (PPR)

PPR Covered Trouble Spots

Has enough information been provided for Project Restart?

 Have you chosen the appropriate architecture for your application?

You might also like