|
Delivering
Software Solutions On-Time and
On-Budget
According to
the Standish Group, only 16% of all software development
projects are delivered on-time and on-budget. A staggering 31%
of projects are cancelled before they ever get completed.
In recent newsletters, we introduced the Iterative
Software Lifecycle and explained how it can help you
consistently deliver software solutions on-time and
on-budget. The phases of this lifecycle
are:
- Planning (Analysis)
Phase
- Design
Phase
- Iterative
Code/Test/Release
Phases
- Production
Phase
Last month, we focused
on the Iterative Code/Test/Release phases. This month,
we will continue our focus on the Production
Phase, the last phase of the Iterative Software
Lifecycle. To see newsletters from prior months, click
here.
This newsletter is sponsored by
Software Planner (http://www.SoftwarePlanner.com).
Production Phase
Once you've
made it to the production phase, the only thing left to do is
to receive a formalized signoff from the testing team and the
customer. Once you have been in production for about a
month, you should conduct a post mortem meeting. The
post mortem is a meeting with the leaders of the development
staff, testing staff and client.
Deliverables
Below are the
deliverables for the Production Phase:
-
Testing Signoff
-
User Signoff
-
Post Mortem Report
The
testing and user sign off is self-explanatory, as it just
allows you to formally document that the testing team has
given the permission to move the release to production and the
client signoff documents that the client has accepted the
release.
For
the post mortem meeting, invite the key members of the
development, testing and client teams. To stay
productive, you will normally want 10 or less people in the
meeting. Ask all participants to bring 3 items to the
meeting that they were done well on the project and 3 items
that can be improved upon.
Go
around the table asking each person the 3 things they
identified as good and bad. Have a moderator assign
someone to list those items on a white board. Then go to
the next person. If that person also mentioned some of
the same things, keep track of how many people mentioned the
same items. That way you can build consensus on the
things people spotted most often.
Once all the items have been identified,
spend time talking about the things you thing should be
improved and make action items for improving those
items. Once the meeting is wrapped up, assign someone to
create the Post Mortem Report. This report should be
distributed to all team members. It should also be
reviewed before starting your next project, as to allow you to
keep track of things that can make your next project more
successful.
Post Mortem Report
We have a
post mortem report template here: Templates for the Iterative
Software Lifecycle.
Below is an example of some of the sections of that
report:
The purpose of the Post Mortem Report is
to describe in detail the specific activities that were most
effective and those that need adjustments prior to the next
test project. A goal of the document is to inform future
project teams of the obstacles encountered during this
release. These activities will focus upon identifying the
following:
·
Processes
which need adjustment
·
Most
effective Processes
·
Providing
Action items
The
following processes were described as positive to the
project.
|
Ref
# |
Category |
# of
Votes |
“Good
Statements” |
|
2.1.1 |
Team Work |
6 |
Good/Responsive
Communication |
|
2.1.2 |
Team Work |
5 |
Cooperation from Program
Management |
|
2.1.3 |
Risk mgmt. |
2 |
Testers stuck to project
schedule |
|
2.1.4 |
Document |
2 |
Test
Plan |
|
Ref
# |
Category |
# of
Votes |
“Need
Improvement” |
|
2.2.1 |
Planning |
4 |
|
|
2.2.2 |
Planning |
3 |
Setup delay |
|
2.2.3 |
Team
Work |
3 |
Project Manager (PM) should be able to review
the detail test plan & test
cases |
|
2.2.4 |
Risk mgmt. |
2 |
Incomplete testing as per the test
plan |
|
2.2.5 |
Planning |
2 |
Functional specification is almost close to
final |
|
2.2.6 |
Team Work |
1 |
Test Case review with
PM |
|
2.2.7 |
Planning |
1 |
Option to start testing sooner – needed more
info |
|
2.2.8 |
Team Work |
1 |
Commitment from everyone who is/was
involved |
The action items themselves must be
concrete and objective, that is: dates must be assigned,
assignees identified, and a form of “measurement” determined
so as to assess the performance towards the action item’s end
objective.
-
Ref # 2.1.1
Continue to be polite and nice. Do not be-little or
condescend someone or his or her input.
-
Ref # 2.1.2
Educate the value of a solid testing methodology and
process.
-
Ref # 2.1.3
Continue to manage risk.
-
Ref # 2.1.4
Continue to review plans.
- Ref # 2.2.1 Resource planning from
management. Currently researching several programs to
retain QA employees. This will require a considerable
amount of effort from the team.
- Ref # 2.2.2 Project Plan should have ample setup
time for hardware. The new test plan templates will prompt
the test lead to ask certain questions about
hardware/software requirements during the planning
stage. This will allow better planning for
configuration management.
- Ref # 2.2.3 Notify Project Management upon completion of
each project deliverable. Our current methodology
would have prevented this. Weekly status reports would
indicate what tasks need to be completed and what tasks have
been completed. These reports would indicate when a
review is required by PM.
- Ref # 2.2.4 Review and Prioritize Test Tasks.
Manage risks associated with slippage. Many times the
project plan is under estimated which causes missed due
dates. One way to mitigate this risk is to stack-rank
the importance of each test case. Also, on larger
projects the business should drive an effort to coordinate
the dependencies on deliverables.
Ref # 2.2.5 Draft form of functional specification will
need to be used in preliminary test planning. The test
plan should refer to sections of the functional
spec. This is a common practice and it should be
noted in our risks and critical dates section. It
needs to be clear to the PM that if the functional
specifications change, it may have an impact on the test
schedule. One tool that would help is the Defect
Tracker software (http://www.DefectTracker.com ). When requirements change e-mail
should be sent to all related parties.
Ref # 2.2.6 During test case creation, periodic peer
reviews need to be conducted by the test lead. After
adjustments have been made to existing test cases, the PM
should review the test cases. With our new test methodology,
this should no longer be a problem. During the
planning phase, a weekly status report will keep all team
members informed of progress and slippage.
Ref # 2.2.7 Start dates for resources need to be
flexible. Test needs to have accurate project
forecasts. Also inform the PM (set expectations) that
we do not have a solution for this one.
Ref # 2.2.8 The quality of testing can be improved when
feedback from the team is documented and analyzed.
This feedback can only be communicated by participation in
the post-mortem process. Solicit feedback during the
project in the form of reviews, stopping by, a phone call,
and triage meetings. Keep notes for the post-mortem
report.
Free
Templates
Click the link below
for some free templates to get you started with the Iterative
Software Lifecycle. These templates cover all areas of the
lifecycle, from the planning to production phases.
Templates for the Iterative
Software
Lifecycle
Software
Planner
Software Planner is a
web-based software lifecycle management tool that fully
supports the Iterative Software Lifecycle. To learn more
about Software Planner, click the link
below.
Software
Planner
|