Building the Release Plan
Developer Breaks Stories into Tasks and Estimates
To enable a customer to assign priorities you need to tell him how long each feature
will take.
Project Plan (Maximum two weeks development) Established
|
Project Plan
As you can see the 4 stories turned into 15 features, 4 have been killed from this
release
Release 1
Release 1a
- Data structure for Release 1 only (8 hrs)
- Zero Feature Release - Setup.exe (16 hrs)
- Menu system - htm with 2 URLs (1 hr)
- Customer form - screen only (8 hrs)
- Order form - screen only (8 hrs)
- Review Mini-Release 1 with Customer (4 hrs)
Release 1b
- Customer Search (16 hrs)
- Customer Add/Edit/Delete (16 hrs)
- CustomerOrderSubform read only (8 hrs)
- Review Mini-Release 2 with Customer (4 hrs)
Release 1c
- Orders + ProductsSubform Add/Edit/Delete (24 hrs)
- Orders Calc (8 hrs)
- Orders Search (16 hrs)
- Review Mini-Release 3 with Customer (4 hrs)
TOTAL - 141 hours or 23.5 days (Note: Days are calculated as 6 hour days.)
Release 2 (The features cut from this release)
- Product form - screen
- Product Search
- Product Add/Edit/Delete
- Order Delivery - automatic order placement investigation for UPS, Fedex, DHL
- Employee form - screen
- Employee Search
- Employee Add/Edit/Delete
- Logon
|
The project plan is used for quoting initially - later it will be used for the customer
to see at what stage we are at. The developer should work down the list of "features"
in priority order. However he can make changes to the order in a mini-release (in
this example he could do 5 before 4) He should let the people involved know the
logic of why he need to do it in a different order via an email. One reason he may
want to change the order, is so that the more difficult parts are done first - this
lowers risk.
Also when creating a project plan the number of releases should be agreed upon.
Some clients like to be actively involved in the project and don't mind being sent
part working copies on a daily basis till project completion, so they can test each
module as it is being built. Whereas other clients tend to prefer not to receive
anything till it is completed and then conduct there own testing on the whole project.
It is important for you and the client to decide upon which method they prefer so
a client not wanting a incomplete release daily/weekly will not get one daily/weekly.
Scenario
RM: Would you like to receive the software in pieces module by module
so you can test each module individually
Client: No I would prefer to be given a completed and working release where
I can test the whole things at once
RM: That would be no problem I will make that clear on the project plan.
Educating and informing the customer is the key to customer relations.
See Rule to Successful
Projects regarding Specifications in Bite-size pieces.
Quoting with a Project Plan
We work on either fixed or variable price contracts. However, even in fixed price
contracts there are always variable elements such as meetings on site.
The quote is produced by adding all the elements from a project plan. You cannot
quote without a project plan. In the example above you will quote for 141 hours
as per Release 1:
- $90 (depending on the resource) per hour for 141 hours = $12,690
We add a 20% margin to the variable cost when we give a fixed price. This is to
cover for contingencies.
- Fixed Price = $12,690 + 20% ($2,538) = $15,210%.
During Release 1 Development, the Customer can get 11 versions, a build is shipped
after every task is completed - these are called "Task Builds." It is
recommended the Client review these versions, but they don't have to. The Customers
must review the mini-releases.
When working on a Fixed-Price a Customer can cancel the order at any time. However,
if part way through a mini-release (5-6 days) the customer must pay for that mini-release
+ a penalty of 20% ($2,538). Just like a restaurant if the cook has started to prepare
a dish, then you pay.
Quoting without a Project Plan
SUBJECT: CLIENTID Development
Dear Sam,
As per conversation we will spend approx 1 day with 2 developers on screens and
working out the scope of the required work - you will get all the screens and we
will continue to make modifications until you are fine with the look and feel.
Regards,
|
When a client requests work that would be outside a project plan or existing specification,
it is important to let the client know that you will be doing hourly-rate work for
the specs. The Project Manager is to:
- Speak to the developer
- See how many new screens are required
- Draft email (don't send)
- Call up client
- Send email to client (cc developer)
Important Note: If the client is not happy to go variable then you need to say to
the client: "I understand you want a fixed price and not an estimate. Fixed
prices are for work that both sides are confident in the scope of work. It doesn't
work for work like this that we don't have specifications that wont change. A fixed
price means you can't have variations. Bottom line in this case you AND SSW will
not be happy delivering software that is not AS GOOD AS IT CAN BE."
Add the
specifications to the web
Maintenance - Updating the Project Plan
Keep the project plan up-to-date daily so your customers can see what you are up
to. Make sure you meet with the customer after every Mini-Release. When updating
it we need to consider the developers productivity. Remember developer productivity
will be the same as yesterdays (just like the weather). See
Rules to Successful Projects
Q: If a project duration is 3 months and after one month the project is one week
later. How late will the project be?
A: Not 1 week...
When Releasing a Version - release to one Client PC at a time
There's no purpose in releasing a new version to multiple users, no matter how small
your client is. Only one person should find bugs. Some clients have dedicated Testers
as part of their IT department, and some don't. In the absence of dedicated testers
it's important that the new version is released to one Client Machine. Never release
a version that only developer's have tested. It's important that the client knows
what are the parts of the new version that need testing.
Onsite Customer
SUBJECT: Onsite Contact
Dear Gary,
Our project has progressed to a point where we need your input. I have made 2 unsuccessful
attempts to contact you in 4 hours. We are working to a schedule, and as per our
agreement we need a representative available at all times during our development
process. We attempt to make the best decision in the circumstances, however if an
incorrect decision is made then the time to change it again is chargeable. I have
decided to make the primary contact read only.
Regards,
|
It is important that we have a customer contact available all the time. If customer
contact is not handy it can cause significant delay to the project duration. We
prefer to have customer working at our premises. If that is not possible, then the
customer must be available by phone or email. The client has a 4 hour condition
to get back to you. Debrief
At the end of each Release it is important to have a debrief where you evaluate
things like:
- Is everything taking twice as long? 1/2 as long?
- Is the customer involved?
- Is the customer being responsive to your inquiries?
- Is the customer testing your mini-releases?
- Are you having fun?
Use the answers for more actual estimates/quotes for the next release.
Collect Stats
The Project Manager is to collect data like number of tests written in a week, tasks
completed, bug reports etc. Don't collect too much data, it will never be referred
to. Don't measure work, like "lines of code", measure productivity, like
"releases".
Coach
A coach's job is to encourage developers, not to be a system architect that makes
all the decisions but works with them to help them make decisions. A person also
needs to manage the personnel and would need to if a developer can not work well
in the team and remove the developer from the project.