Posted on

Waterfalls and the need for agility

Steall Waterfall
A classic waterfall can be made easier to navigate with a bit of agile thinking!

I was out walking at the weekend and the huge amount of rainfall on Saturday night resulted in some spectacular waterfalls on the Sunday, reminding me of a blog I’ve been meaning to write for a while now about my thoughts on the different types of project methodologies.

There are many methodologies for delivering projects, from the traditional Waterfall methodology to the increasingly common Agile approach. Even within these general categories there are specific approaches such as PRINCE 2, APM or SCRUM. There are many people who are firm advocates of one approach or the other, and amongst the project management world I have heard much debate about the pros and cons of each.

Before starting work with various organisations it is not usual for me to be asked about which approach I use, and I will often be advised as to the methodology that is in place at that organisation and which needs to be followed. Though I do believe a consistent approach should be employed across an organisation, or at least a programme of work, so that everybody is working the same way and can understand what is going on; I am not someone who believes that any particular methodology or approach should be employed rigidly within an organisation, nor that it should follow a text book example to the letter.

This may sound like I’m sitting on the fence but this is not the case, it is just that I prefer a more practical approach. I prefer to use a methodology that best suits the organisation, the project and the team who will be delivering it, and if it’s possible to do this within an existing framework then that would certainly be the approach I would recommend.

Never the less I find that in the Digital World there are a specific set of challenges that occur in project delivery which need flexibility and agility to be overcome, however if a purely agile project approach were to be followed then it may conflict with an organisations need for clarity on scope (what is being delivered), timescale (when it is being delivered) and cost.

A diagram of how a more agile waterfall might work
One way of making a classic waterfall more agile

For many organisations the idea of not having a signed off set of requirements, timescale and budget up front is not something that they can easily take on board. However the nature of delivering large scale digital projects does not lend itself well to a purely waterfall approach; a website is not a static entity in that the site is likely to be constantly changing throughout the project, even if this is just purely in terms of content, and these changes risk impacting the way that the end product looks and works if they are not considered frequently throughout the main delivery.

Increasingly, therefore, I am finding that a hybrid approach to delivering projects – where a more traditional waterfall methodology is combined with prototyping and iterative project delivery (a more agile methodology) – is the better way to balance the needs of the technology providers with the business owners.  This more agile waterfall model can take many forms but for me the key is in understanding the business requirements up front, alongside the costs and timescales which may be constraining factors, then working on the solution with all parties (designers, developers and the requestors) in a manner that ensures that if changes are required throughout the build they can be incorporated as early as possible with minimal impact on the overall objectives. By constantly reviewing the delivery with everyone there is less chance of surprises and less chance of the end delivery being unsatisfactory.

I’d be interested in your thoughts. Do you think the days of running a strict waterfall methodology for digital projects are over? Are you an advocate of an agile approach? Or do you too think that the answer lies between them both and will be different depending on the need of the organisation?

If you’d like to know more about reviewing your project methodologies, or need support with a digital project then contact Saja Ltd we’d love to help

 

Posted on

What does ROI mean to your organisation: Innovation or Documentation?

pile of coinsIn an ideal world, the work which organisations do and the projects they undertake have some sort of Return on Investment (ROI): a cost justifiable reason for doing the work in the first place. It could be cost saving or profit increasing, and could be via actual money or via another means such as increased brand awareness, however it is still a cost justifiable reason.

In a formal project management world the Business Case which holds this Return on Investment is a fundamental part of the project kicking off. However for many organisations this just isn’t reality. Projects are often kicked off because somebody somewhere has had a ‘bright idea’ and senior people have decided that it would be a good thing to progress it. This needn’t be a bad thing as, depending on the piece of work, it could be more effort to document the ROI than it is to just do it; and there is an argument that innovation is hampered by the question “why”. Never the less, I do totally believe that if a project is to be successful, and that success is to be measured then the cost/benefit needs to have had some consideration.

The reason I’ve been mulling this over most recently is because I was lucky enough to be able to attend the brilliant Be Good Be Social event in Edinburgh. I was privileged to hear 3 inspiring examples of how the use of Social Media has been effectively harnessed for the good of charitable organisations. The most impressive thing about these examples was that with minimum cost it was possible to achieve huge benefits. The ‘Return’ ranged from increased PR/Awareness and support through to real monetary benefits through donations. The details of the case studies we looked at are on the Be Good Be Social website and a great overview of the evening has been blogged about by Be Good Be Social sounding board member Sara Thomas, so I won’t go into them here. However I can assure you that these guys are great and I love the level of innovation that is demonstrated at their events.

As someone who has done a variety of work for charities over the years, I’ve always been struck by how innovative people within this sector are. Their ideas work to get maximum Return On their Investment, be it their investment of time or money. I don’t know if it is a cultural thing within the organisations, the belief in the cause, or the situational facts (i.e. there is not much money and every penny must be accounted for!). Yet I wonder how often does anyone physically write down a business case, or document expected ROI for this work; or is it that they just wouldn’t ever go ahead and do the work without believing it will bring back value?

It would be a mass generalisation for me to say that this doesn’t happen outside of the third sector, and of course I’m sure there are cases people could cite to me where Charitable causes have been perceived to do work which was without any ROI atall, let alone any innovation. However I do wonder: for these organisations that do look for new and alternative ways to get that little bit more: what is it that drives their innovation? Is it an unspoken, intrinsic desire to maximise ROI, or is it something else more fundamental about the way they work?

Thanks to Ed Henderson (Jack’s Dad!) of Jack Draws Anything, Conrad Rossouw of Shelter Scotland and Lesley Pinder of Missing People for sharing their learnings, and showing how amazing the results of an idea can be!

Posted on

Where to begin


For most web projects, whatever their size, they start with a ‘brief’. The brief comes into play at the point where a decision is made to go forward with an idea and someone is sought to help deliver it. It doesn’t matter if the provider is internal or external but some form of communication is needed to make the idea happen and this is where the brief comes in. The brief can be called many things depending on the organisation; examples include “invitation to tender”, “request for quote”, “design brief”, “website brief”. However in essence they all do the same thing: they inform the potential service provider(s) of what the customer wants so that they can provide a quote or an estimate as required.

question mark over a blank briefOne of the most common concerns I come across working with both agencies and with end clients is the question around what should go into a brief. It is possibly one of the most important documents that is produced, as it sets out high level expectations and will inevitably be referred to further down the line; but it is often one of the weakest documents because of lack of understanding or knowledge of the people producing them at this point in the proceeding. When a brief doesn’t have enough (or the right) information then agencies and service providers find this frustrating because their quote will inevitably be wrong to some degree and a sacrifice on time or money is likely to have to be made at some point during the project. This isn’t good for anyone.

So, in summary, a good brief saves money and keeps good relationships! With this in mind, I have put together a checklist you can use to help ensure that the key information has been covered in your brief. This is not a suggested format, but rather a list of areas which should be covered within the document. The format and how this is interpreted will be different for every piece of work e.g. a brief for a new design for an e-newsletter doesn’t need to be as comprehensive as a brief for a new website, but the salient points remain the same.

Checklist of information to put in your brief

  1. Who are you? Include some background information on the organisation/group/company commissioning the work.
  2. What is the purpose? Give details of what are you trying to achieve and why are you looking for work to be done. By thinking about the purpose of what you are trying to achieve it is easier to break down what you need. This is an area I will go further into on a future blog.
  3. Who is your audience? It is important to think of all the potential types of audience for the concept: who is likely to use it, and who you want to target to use it; and if there are several types of users then it may be appropriate to prioritise them.
  4. Who are your content providers? Provide information on whether or not the content is likely to be static or change frequently, who is going to provide the content and if there is any authorisation process required before it can go live. This all helps ensure a fit for purpose solution that need not incur large ongoing maintenance costs.
  5. What types of content will your web site/application have? Intranets often are used as places where documents and templates are stored for employees e.g. HR forms; however external applications may be less about documents and more about words, video and/or sound.
  6. What support level do you require? Considerations here could be if a website needs to be hosted then do you need backups or a guarantee that the site will be up over 99.95% of time, or maybe you have a requirement for an application to be built for a time specific event and there is likely to be heavy usage during that time, in which case you may wish for extra support.
  7. Have you any branding/logo/legal requirements? These may be dictated by the source of funding e.g. a need to meet certain high accessibility standards, or there may be  corporate brand guidelines that need to be adhered to.
  8. What marketing and user interactive elements do you intend to have at launch/in future? This may not be applicable for all solutions however if you intend to capture user data, or if you are likely to link into Social Media applications then knowing this up front can save you alot of time and money.
  9. Are there any future requirements or technical constraints which should be considered? Considerations here could be the technical platform that your website is sitting on e.g. is it operating on Microsoft or Linux; or it could be that you know in the future you are going to do a large TV advertising campaign and therefore the application needs to be able to support an increase in visitors at that time.
  10. What information do you want to receive back from the companies tendering? If your organisation needs references, prices broken down by various elements, or would like to receive information back from companies in a particular format (word/presentation/hard copies) then informing them up front can save time and confusion later.

Finally: remember the brief produced should give enough information to potential providers that they can return a realistic quote and some potential solutions for your needs. However, the brief should not dictate design or solutions. By working on design and solutions as a collaborative process with the chosen provider (internal or external), you can make use of their expertise to find the best end result.