How to Get Stuff Delivered

how to get stuff delivered

Does your organisation struggle with getting stuff delivered? In this blog post, I show you how the organization, Knightstone Housing, a company I work for is getting stuff delivered. In the last article, I showed how good ideas are raised and become great ideas. Once an idea has passed through the first phase, they go on the awaiting scheduling list. In this article, I walk you through how ideas move from the awaiting scheduling list and get done.

The structure of this blog post is set out with the three approaches Knightstone take to get stuff done. The three approaches of Work Packages, Waterfall and Agile, will be taken one at a time and explained in more detail. After covering the three approaches the last part of the post will be about how projects are brought together and reported on. By the end of this article, you will understand how Knightstone is getting stuff delivered. After reading, you can copy elements of the approach for your organisation.

As I established in my last article Knightstone has established champions throughout the organisation. These people are key to the implementation of successful change. They are managers who have a great understanding of how their team works and would like to work in the future. These champions work with project teams to bring about change to the organisation.

The champions meet periodically to review the awaiting scheduling list — looking at the benefits they sort the list into priority order. The Project Management Office (PMO) use this priority order to schedule the projects.

  1. Depending on the solution design document there are one of three options.
    There is enough information in the solution design; the project is small enough that the estimate is considered reasonably accurate so work can be scheduled.
  2. Is the project better suited to a waterfall approach? In that, all the requirements are gathered upfront and work is scheduled once the detailed requirements are known. A good example of a waterfall project is building a house.
  3. Would an iterative approach be more suitable? Would it be better to have a product backlog with a list of what is wanted? Developments would be done, users would get to use it and provide feedback.

If option 1 is selected, then work can be scheduled

If option 2 is selected then the business analyst will work with the requester to gather detailed requirements.

If option 3 is selected, then the requester becomes the product owner, and the business analyst works with them to produce a product backlog.

I will now take you through each option showing how work gets done.

Option 1 – Work Package

The first option will tend to be simple tasks that require no further information from the requester. There is enough information from the proposal and the design for work to start. The amount of effort will be less than five days with one person completing the work. With this option, it is possible for really good ideas to be suggested and delivered within days. The advantage of this approach is it enables the organisation to make quick small changes. This gives the organisation the ability to react to the ever changing environment. The disadvantage of this approach is it only allows limited small changes that are not complex.

Option 2 – Waterfall

The second option is the waterfall approach. This is like the traditional way of delivering projects. Rather than getting started on the tasks, it has been identified that more information is required first. To take option 2 forward, a business analyst will take detailed requirements and work with the requester to expand them further. The types of projects that these approach suits are ones where it is known exactly what is wanted. A good example of this is taking a current manual process and making part of Knightstone’s system.

The advantages of this approach are everything known upfront before any development is started. There is a set start and finish, so it is known when the work will be completed. The disadvantages are work can not start until the requirements are completed. Any changes have to be formally agreed by going back and updating the requirements. Changes could result in delay and rework.

Option 3 – Agile

The final option is the Agile approach. This is an iterative way of delivering the project. Instead of gathering requirements upfront the Business Analyst works with the requester to develop a product backlog. The backlog is sorted into priority order by the requester. The Business Analyst then adds more detail to each item on the backlog starting with the highest priority first. The team comes together and develops the items on the product backlog in a series of sprints.

The advantage of this approach is the requester can try the product and provide feedback. This enables adjustments to be made before the next sprint. A good example for this approach is designing a webpage. By doing this approach, the requester can use the webpage and then move the location of buttons. The disadvantage to this approach is there could be constant rework to get it right which could lead to higher project costs.

The Go Document

Before work starts we produce a Go Document. The idea behind this document is it gives a summary of what will be done before work starts. It is a bit like when you go to the garage and receive a quote before work starts. The Go Document is very brief and contains the following information:

  1. The problem being solved (the reason for the project)
  2. Benefit of doing the work
  3. How much effort is involved along with any costs
  4. Any high risks
  5. Any known issues
  6. What is in scope
  7. What is out of scope
  8. Plan of what will happen and when

The first two parts of the Go document, the problem and the benefits can be taken directly from the proposal document. Items three, four and five are taken from the solution design document. The final part includes dates when the work will start and finish if it is a work package. If it is a waterfall project, then it will include a Gantt chart. If it is an Agile project, it will include the dates of when sprints will start and finish. Also what is in and out of scope will be included.

With the go document bringing information from other documents, it should not take long to produce. The purpose of the document is to provide clarity to both the requester and the project resource on what will be done and when.

For large projects, the Go document also acts as a business case. This is presented to senior management when large funds or effort is required. It gives them the opportunity to fund the project or stop it before work starts.

With the go document in place, the work is ready to get done. Regardless of which approach is chosen the end result is getting stuff done with lightweight documentation that takes hours and not days to produce. The focus is on getting stuff done as quickly as possible. Even though the focus is on speed, it is still expected that the work done will be of a high standard.

Regardless of which approach is taken the aim is to keep the projects as small as possible. This reduces the amount of detailed reporting on progress, risk and issues. By keeping things simple means, there is no need to produce a massive status report. With the projects small each project should only have one or two risks and issues. Knightstone then roll multiple projects together to make a programme of work. Reporting is then done at this higher level with the focus on what has been done and what is next to be done.

In summary Knightstone have three options to get stuff done:

  1. Work Package (not complex and very small)
  2. Waterfall (requirements first)
  3. Agile (iterative work)

There is also a Go document that provides clarity on what is being done and when. Projects are rolled into programmes for reporting to senior management.

What Knightstone are doing is not worrying about copying the Agile or Waterfall project copybook. Instead, they are focused on getting stuff done in a way that works for them. This may or may not work for other organisations as every organisation is different. It is highly likely that other medium sized companies can look at how Knightstone get stuff done and copy some of it.

Organisations should focus on getting stuff done and doing what works for them. The key is to keep adapting and changing the approach as the environment changes. Continually improvement will see projects continue to get done with a greater level of efficiency.

I have also summarised the key points of Knightstone’s project management approach in a slideshow below. What do you think? Do you like the way Knightstone get stuff done? It would be great to hear what you think, please leave a comment below.

Would you like to get your projects off to a great start? If so you can get a free project start up template by following this link.