Digbyswift is based in Leeds, West Yorkshire offering web and digital solutions. With over a decade of experience in corporate and agency web development, Digbyswift can meet and support your requirements, whether it be MVC or web forms development, Umbraco, bespoke CMS build and maintenance, ecommerce, SEO and Google analytics or even client training. Read more ...

Benenden Fertility goes live with Umbraco

By Digbyswift at May 31, 2011 13:55

I’ve recently finished a contract for a client developing a new, great looking site for Benenden Fertility, part of the Benenden Hospital Trust.

 benenden benenden_2

I used Umbraco 4.7 for this project since two previous projects had used Umbraco 4.5 and I wanted to delve into the changes but also wanted to push my client’s dev team into new pastures too!

I had originally estimated 2 weeks for the site build and am pleased to say the site was delivered on time with Benenden very happy with the results.

What I am especially pleased with was the lack of fixes or changes required by Benenden as a result of their internal testing, prior to go-live. In a nutshell, this means that:

  • The brief was good;
  • The spec did the job;
  • The dev process held up;
  • The QA process worked;
  • The communication between me, my client and Benenden was successful.

Of course, there is always room for improvement:

  • The spec wasn’t actually very good and I had to ignore most of it, checking only that I had not missed anything important;
  • The dev process did hold up but bad habits had to be compensated for by stringent QA;
  • QA was done entirely by the dev team and the designer. Surely this should never be the case.

Realistically, this is still pleasing since if the project had been perfect I would have been scratching my head wondering what I’d missed!

Most importantly for me though, is the fact that because the site was on time and that the Benenden was happy, my client’s dev team are reassured that they can meet deadlines and their work isn’t always strewn with errors and bugs. This in turn creates a happier team environment, and makes my client happier too.

Hoorah for Umbraco.

Handling the impossible project

By Digbyswift at June 24, 2010 05:56

I’m currently finishing the first phase of a project that has caused a few sleepless nights. The causes I can comfortably lay at the door of my boss:

  • He agreed a fixed fee up front with the client without any analysis of requirements;
  • He agreed a go-live date up front, again without analysis of requirements.

You might say that this is actually not an issue. This happens all the time, right? How many projects have you worked on when you’ve actually known the budget? Or when the specification for the project has been written after the horse has bolted?

Sure, this probably isn’t an issue if the project is relatively small and one that you can boilerplate from another project. However, in this case, the client wanted us to build an e-commerce/auction application, that once spec’d out required approximately 1050 man hours – that’s around 30 weeks, one developer working flat-out. This also making the assumption that I had captured all the tasks – which inevitably I hadn’t.

My boss promised up front that the client could have it in 12 weeks.

Every developer knows that given any week of development, he will not get 100% development time one one project. Maybe, 75-80%? The rest will be meetings, helping colleagues etc. So, to me, the task was ludicrous. Even with two developers working flat out, the timings still did not add up.

I’ve done my math and the fixed fee agreed with the client, before any specification was written, requirements analysed etc. was a hefty 5-figure value short of just the development cost. Add to this the cost of design, planning, project management costs and then contingency, and you can see that this is simply ludicrous.

This is what we did

So in a nutshell, this is what we did:

  • Myself and another developer worked flat out for the 12 weeks;
  • We hired a contractor to do a independent chunk of the project;
  • We drafted in a third colleague at times to pick up certain tasks;

The 4 weeks testing originally scoped, became 1 week and then the site went live.

The result

It was not my intention to go live after such a short testing period. In fact, no internal was done at all and barely one week of client testing. But the client wanted it live and we weren’t in a place to argue. The result was that a sub-standard site was released to the public:

  • There was missing functionality;
  • There was buggy functionality;
  • There was functionality that just didn’t work;
  • The work the contractor had done was untested and error strewn;
  • The client required changes that were difficult to incorporate due to the buggy nature of the site;
  • The client required changes that they hadn’t realised they wanted till they saw a complete, functioning version of the site.

In addition to this, because the testing phase was cut short and, as it turns out, the client didn’t sign off the specification, the issue-fixing stage will be ongoing for quite some time.

Lessons learnt?

Its easy to say, but don’t let your boss promise anything to the client until a project brief has passed your or the lead developer’s eyes.

How can a project be costed if there is no analysis of what the project will actually entail?

You may upset your boss by insisting on being involved as it will be seen that you are overcomplicating a process that he/she needs control over. But the benefits out-weigh the additional time spent, even if this is 30 minutes doing a high-level analysis of your bosses interpretation vs. the clients brief.

I’m actually very happy how the project has turned out. I’m less happy about the stress that it has caused. But it has up-skilled members of the team, given colleagues the encouragement that larger projects, when handled in a certain way needn’t be difficult and shown core weaknesses in the company’s project delivery process that we can improve upon for next time.