What Matters More? Speed or Perfection?

In my various travels online today I came across an interesting post Taking Stock on the Museum in a Day web site, the blog used to keep track of a project to start and finish a museum based site in a day using cheap and cost-effective means to design, code and implement.

Of most note was a comment made about half way through the post itself:

“… although no museum is every likely to (want to!) build a website in a day, there is a tendency for the timescales created by the political nature of museum decision-making to actively damage projects. The raw enthusiasm and energy that is created by doing things rapidly, cheaply and – frankly – without the polish of perfection – is hugely important to any project.”

Having been fired up with a passion for an idea before now, I completely understand where this point is coming from.  Capturing that raw unfettered power of enthusiasm and harnessing it for some good is critical to the success of a project and the maintenance of that ‘esprit de coeur’ throughout the lifetime of any project is also key to its success.

Any aspect of a project and the management of it, from planning to execution, needs to be underlined with best practice. As projects become more and more drawn out there is an easy tendency for them to veer away from the initial intent, for changes, scope creep and backtracking to occur, which undermines the will and the drive of those actually putting things in place, the developers.

To maintain a critical mass for any project and for it to succeed you need to apply yourself in a dogged fashion and to persevere.  The following high level overview to do so makes sense:

• Draw up an outline – What you wish to put in place and how this ultimately benefits your site users.
• Break down the workflow – Assign tasks based around the outline and agreed means implementation.
• Build, Test and Roll-out – Get on with it and finish it as quickly as possible.

Getting from A-B as quickly as possible makes total sense, on many different levels, but mainly because it avoids deviance from the initial plan.  Any incoming requests for changes, unless critical, should be pushed off to a second phase of, yes you guessed it, another round of A-B.  Some of the beneficial side effects of this route, include, but are not limited to:

• Savings – Both in terms of cost and time, less time spent = less money spent.
• Quality – Deviance, changes and more only lead to hacky code that requires re-factoring in the long run, proper planning and execution of said plan tend to avoid this, notwithstanding poor coders.
• Feedback – Following up on yesterday’s long post, smaller, iterative, implementation phases allow for feedback earlier in the process so bigger changes don’t have to be made later.
• Thought – in waiting for the following phase to start, this gives you time to think about your needs and desires, and to search out evidence and justification for the requests you want to have implemented.

Working with so-called stakeholders, managing their expectations and making sure that they now when and how their input is required in the process and the implications of any requests, and how they fit into the grand scheme of things will help ease the flow of the project.  Constant and disruptive input can only harm your project, whilst at the same time, elongated time lines and the opportunities it provides to upset initial implementation plans provides exactly the same issue.

So back to the starting point?  What makes sense? Speed or perfection?  To my mind speed.  This is because speed doesn’t mean reaching an end, and then stopping, with no more opportunity to finesse a product, but to accomplish set goals as quickly as possible and then to move on as quickly as possible the next ‘pre-planned and scoped’ phase so that everything can be outlined and accomplished in an orderly and sensible fashion, without undue and unnecessary pressure.