Select a "Product Owner" - who is the sole person able to make scope decisions and authorize work.

Remember it's all too tempting to allow the DBA to authorise work without seeking proper authority, so insist that your software consultants follow the standard on getting work approved through a Product Owner.

If you are using Scrum:

• The sprint backlog is approved by the Product Owner (the customer)
• The Dev team is working to the sprint backlog (usually 2 weeks)The Scrum Master is ensuring the client is kept up-to-date (via the Review, Retro and Planning meetings) #1
• The Scrum Master is ensuring the client is kept up-to-date (via the 4 reports)
• The Account Manager is booking in future sprints (after the Planning Meeting)
• The Account Manager invoices (usually every week).

If you are using the old waterfall method:

• The specification is approved by the customer
• The Dev team is working to the specifications (for anywhere from 2 months to 2 years)
• The Project Manager is ensuring the client is kept up-to-date (via ad hoc meetings)
• The Account Manager sends invoices when milestones are met.
  

Some clients think that a Project Manager is just a resource that increases the cost of a project. But a house does not get built if you leave the architect, carpenters, electricians and plumbers to just work it out between themselves. The house *does* get built if the foreman is keeping everyone on their toes, making sure they are doing their job.

Insist that your Scrum Master (aka Project Manager) maintains a strict project schedule.

For more information go to Scrum Terms and Scrum Roles .

​A 1 week sprint is for small projects (of < 2 months) or if constant visibility into costs is an important factor, as it gives better feedback to the Product Owner (you)
Note: This can be at the cost of increased overheads.

A 2 week sprint is the most common and allows a reasonable amount of work to be done for each release, while minimising Project Management overheads.

A 4 week sprint is a smell.

It is important to note that as more project management overheads are added, these will have to be paid for. The outcome is, as quoted by Ulysses Maclaren, "The more you want to see how much you're spending, the more you'll spend".

It's important to find the right balance for you.

Pros:

• Productivity improvements (faster and cheaper development)
• Less conversion issues later
• Happier Developers
• Potentially a competitive advantage
• Development environments are likely current and so don’t need time to setup

Cons:

• All issues are not necessarily known yet and workarounds may need to be found
• Backwards compatibility (you may have users who have to use an older platform and new techs may not work for them)

One major issue with using old technologies is that you will often be up for additional costs to set up suitable legacy development environments. i.e. SQL 2005 Server, Windows 7 running VS2008 etc. and then there are bills for ongoing charges (if required to host and store dormant VMs)

​This is done during the planning meeting and will ensure the availability of the developers who are up to speed on your project and stop them from being booked onto something else.

Figure: If you have booked the guys in, you will have an appointment like this in your Outlook.

'Bugs' are generally a consequence of the development team not knowing every possible scenario when adding error handling. Generally speaking it takes developers just as long to add the error handling before you test it than after you test it. Bugs can also occur when development requirements change on the spot or work is not sufficiently specified.

For these reasons, fixing such issues is generally billable work on time & material contracts. On fixed-price contracts, bugs are generally fixable within the warranty period at no cost to you.

What is a bug?

"I want to keep contact details on my clients"
Figure: Bad example - likely to require later clarification.

"I want to record my clients' firstname, surname, mobile phone, email address & Instant Messenger address."
Figure: Good Example - You'll get exactly what you want. Even better, use screen shots or mock-ups.

The best way for this to work is to break tasks into the smallest possible bite size pieces and ensure that those pieces are in the project plan explicitly.

Sometimes software developers miss a related item which you might consider 'blindingly obvious.' For example you might ask them to fix a combo box on one form in a legacy application. But they mightn't know about the three other forms that the same type of combo appears on. So if you also want them fixed, then let them know about them!

Get UI Changes OKed 

Insist your software consultants conduct specifications by creating mock-ups.

Software developers send many queries via email, we ask that you pay close attention to your Inbox and respond promptly.

Insist your software consultants follow the standards to better email

Once again it's a matter of working with your developers in being clear in requirements and testing as changes are made to ensure these issues are trapped as early as possible.

Ask your SSW developer to add a test case which will mean in the future important functionality will never "disappear" or break. The earlier you do this, the less pain you'll have down the track.

My Father-in-Law is Greek and I have noticed he gets more out of a tradesman than anyone else. Bottom line is he watches what they're doing and then gets on their case early when things aren't perfect. Whether it's carpet layers not matching the patterns together or plasterers leaving unsightly corners - as soon as he spots a problem he confronts them straight away and gets them to rectify it.

With any professional consultant or tradesman you should always take a hands-on approach with the project, stay on top of the important issues, and be ready to get involved when you see a problem.

Of course, as your relationship builds with the consultant or tradesman, and they become more aware of your expectations, you can divulge greater trust and leave them to it.

So you should insist that your software consultants maintain verbal contact with you (before resorting to emails).

They should then use “as per our conversation” follow up emails.

Tip: A nice way to know what is going on is going on is to turn up to the daily scrum.

​It's very important that these are your highest priority items as these will be prioritised over anything else for this sprint. If you want any changes made, contact the team as soon as possible.

For more information on Sprint Forecasts, see http://rules.ssw.com.au/Management/RulesToBetterScrumUsingTFS/Pages/Do-you-have-a-Sprint-Contract-aka-The-deal-between-the-Product-Owner-and-Team.aspx 

• Project Progress ($ spent)
• Burndown (ETA)
• Story Overview (testing quality)

Let's look at those 3 reports:

1. Current project costs

This allows you to see the actual costs of the project on a weekly basis.

2. Current hours remaining and hours completed for the current sprint

Questions that the Burndown and Burn Rate report help answer:

1. Is the team likely to finish the iteration on time?
2. Will the team complete the required work, based on the current Burn Rate?
3. Has the team added work to the iteration?
4. How much work does each team member have?

How to Use the Burndown and Burn Rate Report

Story Overview - See how each task is tracking

Questions that the Stories Overview report help answer:

1. How much work does each story require?
2. How much work has the team completed for each story?
3. Are the tests for each story passing?
4. How many active bugs does each story have?

How to Use the Stories Overview Report

Managing additional work requests can reduce the adverse impact on estimates and deadlines.

Figure: Only if it's life and death does it get added "in this sprint"

The first step is to analyse the priority of the additional item.

Let's look at the rules to how to prioritize:

1. By Default, move Tasks into the Next Sprint.
   Priority is dependent upon the severity of the request. Only if it is a 'critical bug', then it will be done "in this sprint", most tasks however go "in a later sprint". They can include new feature requests, non-critical bug fixes, modifications and undiscovered work (i.e. work you didn't initially anticipate). 
   Note: On a fixed price contract the rules change. Bugs should be fixed in the current sprint if time allows, otherwise first thing in the next sprint as they are stopping you from being paid.
2. Exception #1 - Critical Bugs go into this Sprint
   If you have a crash-to-code bug, most of the time it will go into this sprint. If it prevents one or more users accessing the system, it will  go into this sprint. Only high-priority bugs are fixed "in this sprint".
   
   On the other hand, a bug that was in the prior sprint and not marked as a task in this sprint, generally will be moved into the next sprint. Everything in between is grey :-( 
3. Exception #2 - A Client can Override
   A request for a new screen with a new look-up table that doesn't prevent users from operating the system, should be allocated to "a later sprint".
   If the client really *needs* it done now, they must specify "must be in this sprint". This will become an 'additional item' in the current sprint. If this request from the client will have a material impact on inflexible time and budget restraints, you need to speak and inform the client.
   For example:
   "Hi Bill, this task you specified 'must be in this sprint' will take an extra 4 days. Our critical deadline will be missed. Is that OK?"
4. Exception #3 - A Developer can Override
   A client may request a small feature (e.g. changing the sort order of a combo-box). This work can go in this sprint as long as the task is small (less than 1/2 hour) and the sprint is under budget.
   If the work is over budget then you need to obtain approval for any 'additional item', from both the project manager and the client, before adding the request into the Release Plan. See more about how to Obtain Approval Additional Items Exceed Estimates.
   

   To: Evan Lin - SSW
   From: Alan Ha - FinaMetrica
   Subject: Client List for Administrators
   
   Hi Evan,
   
   Please add a sort function (like the one in office 2007) next to the fields: Last Name, First Name, Advisers and Organization. Apply to other relevant pages which have these fields in a list
   i.e. adviser list for administrators, client list for advisers etc.
   Please use the text Ascending instead of "smallest to Largest" and Descending for "Largest to Smallest".
   
   Thanks Alan
   
   

   Figure: The above is a sample from a customer will by default, go into a later sprint, not the current sprint.

   What tools can you use to get tasks from your inbox into a task tracking system?
    
5. Use a Good 3rd party Tool to Manage Additional Requests
   

   Since most feedback comes into your Outlook inbox, find a tool that converts an email into a task. The best one is TeamCompanion for TFS

Your budget and deadline may mean some items will not get done.

Sometimes their estimates on items are way too short or too long. It is very hard to be 100% accurate when estimating hours to complete work.

The best way to keep track is to insist on a weekly release update/debrief.

Every new item that is requested increases the total hours and scope of the project and therefore the cost. If the project has a drop-dead date or budget, don't ask for things that will blow these deadlines out. Or, if you want your developers to work to a budget, ask them to let you know what 'can't be done.'

Insist your software consultants correctly triage additional item requests.