 |
| |
|
|
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 Design Phase, specifically the Data and Object
Models. This month, we will continue our focus on
the Design
Phase,
the second phase of the Iterative Software Lifecycle.
Since the design phase has many deliverables, we will focus
this month on the Project Plan, Budget, and
Signoff deliverables. In the coming months, we
will explain the remaining phases of the Iterative Software
Lifecycle and provide you with step-by-step instructions on
implementing it. To see newsletters from prior months,
click here.
This
newsletter is sponsored by Software Planner (http://www.SoftwarePlanner.com).
Design
Phase
The Design Phase is used to determine the
technical solution and to provide preliminary estimates for
delivering the solution. For the project manager to
provide correct estimates, the development team must spend
time architecting a technical solution that meet the demands
of the functional specification. Additionally, the
testing team must develop a Master Test Plan as to allow them
to estimate their effort.
Upon completion of this
phase, a project plan may be developed which details the
costs, effort and timeframes in which the solution may be
delivered. As a final step, the client may decide to
add, omit or delay functionality to fit within their timeframe
and budget.
Deliverables
Below
are the deliverables for the Design Phase:
Since we discussed the
Data and Object
Models last month, this month we will discuss the
Project Plan, Budget and Signoff deliverables.
Project Plan
Once
the functional specifications have been gathered and the
detailed design is complete, the project manager can begin
laying out the project deliverables and the calculating the
budget for the project. As we mentioned in one of our
previous newsletters, when collecting
functional specifications, you should always number the
functional specifications in a hierarchical manner. That
numbering system should follow directly over to the Project
Plan, as it allows you to easily trace your project
deliverables back to your functional specifications.
When devising the Project
Plan, sit down with your team to ensure that all deliverables
are flushed out. This includes all tasks associated with
the project, from the Planning phase to the Production
phase. For a typical software project, you may decide to
organize your project plan with the following major
sections:
-
Planning - These are
the deliverables discussed in the Planning phase.
-
Design - These are
the deliverables discussed in the Design phase.
-
Construction - These
are the deliverables for the software construction.
-
Testing - These are
the testing delivereables (QA and User Acceptance
testing).
-
Implementation -
These are the deliverables for rolling out the product to
production.
-
Project Closure -
These are the final activities used to evaluate how the
project
went.
Below is a sample project
plan that illustrates these concepts. Notice that costs
are associated with task item, allowing budgeting to become an
automatic part of your project plan. Notice that all of
the tasks are numbered hierarchically. These numbers
should match the numbering system you used when developing the
functional specifications. This eases requirements
traceability.
| Project Deliverable |
Cost |
Hours |
Begin |
End |
Pred |
Resource |
| XYZ Corporation Fleet
Mgt System |
$67,625.00 |
541 hrs |
08/12/02 |
11/06/02 |
|
|
| 1.1 Planning |
$9,250.00 |
74 hrs |
08/12/02 |
08/23/02 |
|
|
|
1.1.1 Initial Customer Requirements meeting |
$1,000.00 |
8 hrs |
08/12/02 |
08/12/02 |
|
PM |
|
1.1.2 Develop Functional Specifications |
$5,000.00 |
40 hrs |
08/13/02 |
08/19/02 |
3 |
DEV1 |
|
1.1.3 Functional Specifications Review/Chgs |
$3,000.00 |
24 hrs |
08/20/02 |
08/22/02 |
4 |
PM |
|
1.1.4 Functional Specifications Signoff |
$125.00 |
1 hr |
08/23/02 |
08/23/02 |
5 |
PM |
|
1.1.5 Risk Assessment |
$125.00 |
1 hr |
08/23/02 |
08/23/02 |
6 |
PM |
| 2.1 Design |
$15,750.00 |
126 hrs |
08/23/02 |
09/13/02 |
2 |
|
|
2.1.1 Design Meetings |
$3,000.00 |
24 hrs |
08/23/02 |
08/28/02 |
|
DEV1 |
|
2.1.2 Detailed Design Document / Use Cases |
$5,000.00 |
40 hrs |
08/28/02 |
09/04/02 |
9 |
DEV1 |
|
2.1.3 Test Design |
$4,500.00 |
36 hrs |
09/04/02 |
09/10/02 |
10 |
TESTER2 |
|
2.1.4 Object Model |
$1,000.00 |
8 hrs |
09/10/02 |
09/11/02 |
11 |
DEV1 |
|
2.1.5 Data Model |
$1,250.00 |
10 hrs |
09/11/02 |
09/12/02 |
12 |
DEV1 |
|
2.1.6 Project Plan |
$500.00 |
4 hrs |
09/13/02 |
09/13/02 |
13 |
PM |
|
2.1.7 Budget |
$250.00 |
2 hrs |
09/13/02 |
09/13/02 |
14 |
PM |
|
2.1.8 Customer/Dev/Test Signoffs |
$125.00 |
1 hr |
09/13/02 |
09/13/02 |
15 |
PM |
|
2.1.9 Risk Assessment |
$125.00 |
1 hr |
09/13/02 |
09/13/02 |
16 |
PM |
| 3.1
Construction |
$21,500.00 |
172 hrs |
09/16/02 |
10/15/02 |
8 |
|
|
3.1.1 Functional Requirement 1 |
$5,000.00 |
40 hrs |
09/16/02 |
09/20/02 |
|
DEV1 |
|
3.1.2 Functional Requirement 2 |
$7,500.00 |
60 hrs |
09/23/02 |
10/02/02 |
19 |
DEV1 |
|
3.1.3 Help System |
$3,000.00 |
24 hrs |
10/02/02 |
10/07/02 |
20 |
DEV1 |
|
3.1.4 User Documentation |
$3,000.00 |
24 hrs |
10/07/02 |
10/10/02 |
21 |
DEV1 |
|
3.1.5 System Documentation |
$3,000.00 |
24 hrs |
10/10/02 |
10/15/02 |
22 |
DEV1 |
| 4.1 Testing |
$20,250.00 |
162 hrs |
09/16/02 |
11/05/02 |
|
|
|
4.1.1 Test Design |
$5,000.00 |
40 hrs |
09/16/02 |
09/20/02 |
17 |
TESTER1 |
|
4.1.2 Iterative QA Testing Cycle |
$10,000.00 |
80 hrs |
10/15/02 |
10/29/02 |
18 |
TESTER1 |
|
4.1.3 Iterative User Acceptance Testing Cycle |
$5,000.00 |
40 hrs |
10/29/02 |
11/05/02 |
26 |
USER1 |
|
4.1.4 User Acceptance Signoff |
$250.00 |
2 hrs |
11/05/02 |
11/05/02 |
27 |
TESTER1 |
| 5.1
Implementation |
$375.00 |
3 hrs |
11/05/02 |
11/06/02 |
24 |
|
|
5.1.1 Installation |
$250.00 |
2 hrs |
11/05/02 |
11/05/02 |
|
DEV1 |
|
5.1.2 Rollout Notification |
$125.00 |
1 hr |
11/06/02 |
11/06/02 |
30 |
DEV1 |
| 6.1 Project
Closure |
$500.00 |
4 hrs |
11/06/02 |
11/06/02 |
29 |
|
|
6.1.1 Post Mortem Meetings |
$500.00 |
4 hrs |
11/06/02 |
11/06/02 |
|
PM |
Budget
If you are using a commercial
project planning tool (like Microsoft Project), you can
automatically calculate the budget as you are setting up your
project plan. Once your budget is calculated, your
client may want to re-evaluate their functional specifications
to try to trim costs or to speed the delivery of the
product.
For a project to succeed, there are 3 variables
that affect how quickly a project can be completed:
Resources, Schedule and Features. One of the
variables must always be flexible to achieve success.
For example, if the client has a fixed number of resources
(people that work on the project) and their schedule has been
set in stone, the feature set must be flexible. This
means that they must be flexible to drop some features to make
the pre-determined date with that number of resources.
Project Trade-off
Matrix
|
|
Inflexible |
Flexible |
|
Resources
(Cost) |
|
|
|
Schedule
(Ship Date) |
|
|
|
Features |
|
|
Working together, the team and customer place a
check mark in the appropriate column for each of the project
variables. The columns are defined as:
-
Inflexible.
Mark 2 items that are inflexible. For example, if the
cost and ship date are set in stone, make Resources (Cost)
and Ship Date as Inflexible. Only 2 items can be
inflexible, the last item must be flexible.
-
Flexible. Mark one item as
flexible. For example, if you are flexible with the
features that are included in the project, mark Features as
Flexible.
A team should use the project trade-off matrix
as a reference when making decisions. The matrix is not
intended to show absolute priorities; it is merely a tool to
facilitate communication and understanding. Most important for
the project team is that the matrix shows areas in which the
customer is willing to compromise. Make sure that no row or
column in the project trade-off matrix has more than one check
mark. Any other combination poses serious risk to the project
and must be accounted for explicitly in the risk management
plan.
In order for a team to be successful, at least
one check mark must be in the “flexible” column. This means
that the team owns at least one variable so that the team is
empowered to manage change and risk, and is therefore
positioned to achieve success instead of failure.
Signoffs
The final deliverable in the
Design Phase is signoff. You should get signoff from
these 3 teams:
-
Customer - Customer
should sign off on the functional specifications, project
plan and budget.
-
Development - The
development team should sign off on the functional
specifications and detailed design.
-
Testing - The
testing team should sign off on the functional
specifications and the test design.
Summary
During the Design Phase, the project manager
works with the development team to create detailed
designs. Detailed Designs explain the technical approach
and estimated effort for delivering each functional
specification item. Once this is done, the project manager
works with the testing team to create the Test Plan. The
Test Plan details the testing approach and estimated
effort. Once this is done, the project manager can fully
estimate the entire project and your development team can
create the Data and Object models. The Data and Object
models should have clear standards as to enforce consistency
as multiple team members work on the project. Finally,
the project manager creates the project plan and budget for
the project, getting signoffs from the customer, development
and testing
teams.
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
| | |