⚠️ This page has been archived

✅ New page with updated info: ssw.com.au

Home > Archive > SSW Standards > Rules > Rules to Better Project Management Methodology

Do you agree with them all? Are we missing some? Let us know what you think.

  1. Building the Release Plan

  1. 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
    1. Data structure for Release 1 only (8 hrs)
    2. Zero Feature Release - Setup.exe (16 hrs)
    3. Menu system - htm with 2 URLs (1 hr)
    4. Customer form - screen only (8 hrs)
    5. Order form - screen only (8 hrs)
    6. Review Mini-Release 1 with Customer (4 hrs)
    Release 1b
    1. Customer Search (16 hrs)
    2. Customer Add/Edit/Delete (16 hrs)
    3. CustomerOrderSubform read only (8 hrs)
    4. Review Mini-Release 2 with Customer (4 hrs)
    Release 1c
    1. Orders + ProductsSubform Add/Edit/Delete (24 hrs)
    2. Orders Calc (8 hrs)
    3. Orders Search (16 hrs)
    4. 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)

    1. Product form - screen
    2. Product Search
    3. Product Add/Edit/Delete
    4. Order Delivery - automatic order placement investigation for UPS, Fedex, DHL
    5. Employee form - screen
    6. Employee Search
    7. Employee Add/Edit/Delete
    8. 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.