Closed clubs

[Clive Coles]

I think some of these problems occur because we take a long time discussing and developing something new and then experience pressure to implement in a hurry.

Some matters, like the uncertainties regarding Local Club ranking eligibility, are less serious. In the heat of the moment BOF didn't appear to notice the contradictions on their web site. Seems to have been quickly addressed though I am still not convinced the program is working properly. Noticed this morning some of our club members had actually disappeared from the list. Either program changes were made overnight or an old result tripped over the 12 month mark.

Other oversights however are more serious as they probably require data model changes. There is a danger we will be told by the developers that changes will be expensive and BOF will decline to change things.

I found during the development of the new fixtures system BOF were very reluctant to disclose their data structures or the underlying derivation or data mapping models.

With a bit more scrutiny of the data model at an early stage it is probable matters such as second club membership , mixed event levels within a multiday could have been noticed and accommodated within the solution.

But we are where we are.

[madmike]

But we are where we are.

That's true but how do we get to where we should be (or even where we used to be)? My issue, which sparked Snail to start this thread, is the dismissive stance that we simply don't do it anymore. Progress/what Progress?

Successful implementation of IT-enabled business change is, imho, 90% defining requirements properly (a lengthy iterative process) and 10% hiring some code monkeys to write the software. We appear to have employed the code monkeys too early (after iteration 1 or maybe iteration zero?) and hence have delivered a new system that is less effective than the obsolete one it replaced.

When will we ever learn

[EddieH]

Remember the very expensive results software that BOF put out to tender several years ago.

I seem to remember that Mike Napier tendered and failed. As soon as the contract term for the winners was over they were dropped like a stoneand Mike took over

This latest escapade has been massively more productive than that one was.

[pyrat]

[
Successful implementation of IT-enabled business change is, imho, 90% defining requirements properly (a lengthy iterative process) and 10% hiring some code monkeys to write the software. We appear to have employed the code monkeys too early (after iteration 1 or maybe iteration zero?) and hence have delivered a new system that is less effective than the obsolete one it replaced.

Creating requirements tomes and treating developers like monkeys suggests you are not paying enough for your developers.

[greywolf]

Well I believe Mike works for an organisation famous the world over for its ability to procure new systems and hardware on time and at the original budget....

[Scott]

These folks appear to be the developers that BOF have been using.

[Angry Haggis]

These folks appear to be the developers that BOF have been using.

Interesting:

We were originally drafted in late in the project to oversee development. Over time it became apparent that the developers did not have the skills to bring the website to completion. Along with the team at the British Orienteering Federation we decided to take over development of the website and reworked the code in order to get the site live. Within a month of taking over the build the website was put live.

[Scott]

Yeah. I'd be interested to know whether by "website" they mean the current website as a whole, or whether they were called in because of problems with one of the more recent additions (eg. the fixtures system, or the results/rankings).

[geomorph]

[
Successful implementation of IT-enabled business change is, imho, 90% defining requirements properly (a lengthy iterative process) and 10% hiring some code monkeys to write the software. We appear to have employed the code monkeys too early (after iteration 1 or maybe iteration zero?) and hence have delivered a new system that is less effective than the obsolete one it replaced.

Creating requirements tomes and treating developers like monkeys suggests you are not paying enough for your developers.

Oh-oh; a one dimensional approach on three dimensional terrain. The change method utilised depends on the change itself and the character of the organisation in which it is to be enacted. It's a bit like route choice, you choose a route deploying one or many navigational techniques that are appropriate to get you there in the way you want, evaluating and managing the approach/route risks, and respecting navigational and physical challenges of the terrain you are crossing. Sometimes getting the coders in early is the best way to drive forward the requirements definition and can significantly reduce the formalised approach to that definition, and eliminate costly translations from English to business requirements diagrams to code specifications to final code. But choose your intermediate and final attackpoints well, keep in touch with the map,and be prepared to make adjustments if things don't pan out as expected.

So, orienteering is a valuable training technique for business change process enactment. Sell your club training programme now

[andy]

More interesting than the actual thread is the requirements vs development argument!

if you think software development is 90% requirements and 10% coding, well, you're wrong. you're right it needs to be an iterative process but that process needs to include the developer(s) at a very early stage.

The worst experience is receiving a very thorough requirements doc and a writer of said doc who thinks they won't need to put in any further input. If some questions arise they are generally dismissive and will say things like 'go read the requirements'. This produces bad, incorehent software.

The best is a concise but well written requirements doc, with a writer who says 'that's what we want, go write a prototype then we'll meet and see where we go from there'. They will answer your questions and be open to discussion. It produces good software.

Developers and end users like option 2, beaurocratic types like option 1 (generally), which is sad because it's the beaurocratic types who make the decisions

[Scott]

Mike Hamilton did use to work in software development, so hopefully BOF should be better off in that respect than a lot of organisations.

[madmike]

Well I believe Mike works for an organisation famous the world over for its ability to procure new systems and hardware on time and at the original budget....

Oh if only we were permitted to procure new systems and hardware ourselves but that's a discussion to be had over a bottle of red somewhere

[madmike]

More interesting than the actual thread is the requirements vs development argument!

if you think software development is 90% requirements and 10% coding, well, you're wrong. you're right it needs to be an iterative process but that process needs to include the developer(s) at a very early stage.

The worst experience is receiving a very thorough requirements doc and a writer of said doc who thinks they won't need to put in any further input. If some questions arise they are generally dismissive and will say things like 'go read the requirements'. This produces bad, incorehent software.

The best is a concise but well written requirements doc, with a writer who says 'that's what we want, go write a prototype then we'll meet and see where we go from there'. They will answer your questions and be open to discussion. It produces good software.

Developers and end users like option 2, beaurocratic types like option 1 (generally), which is sad because it's the beaurocratic types who make the decisions

don't confuse getting the requirements right with a requirement document or developers with code monkeys

[EddieH]

Well as a past database developer it s clear that a second club field is a piece of inert data which will be used for nothing other than to print on a bit of card. It has no structural impact on the system and consequently could be instigated with extreme ease - it needs a tiny addition to one data inputting bit of code, and another to one output (printing) bit of code. If that costs the earth someone's taking the mikey.

[Clive Coles]

This thread is now getting to the core of a wider different problem ~ BOF made some costly mistakes concerning how they defined and managed the entire BOF web site project.

It was based on a vision. The full requirements were never outlined and agreed before software developers were brought in and they started crafting code.

The original Fixtures registration specifications were never reviewed by a represtative body such as the National Fixtures committee. To be fair the original developers probably worked on the specifications Mike gave them .

Then the original developers ceased trading. Rather an embarassing situation. This was about the time that the fixtures software was being passed into beta test. This was the first time anyone from the National Fixtures committee got to see what BOF had spent our money on.

The initial beta test versions of the Fixture facilities were unuseable ~ it took a further 11 months of review followed by re-enginering before the facilities were fit for purpose. I think what the new software developers have salvaged is the best they could do on a constrained budget.

In my experience cutting code is the easy bit. Requirements definition. scoping project deliverables, developing the underlying data model, planning and testing take up much more time. These are the activities that are just as critical for a successful implementation.

Development needs to be iterative. At every stage you need to build in checks to scrutinise and review. You need a clear idea what you want from the system before you finally conclude the design and contents of the data model. Reviews need to bring together developers and end users ~ this did not happen with this development.

BOF would not discuss output until the final phase of the implementation. But by this stage it was to late to change the data model. We have got what we deserve, take it or leave it.

The sad thing is that is just what a lot of clubs are doing. They are not updating their fixture registerations with such useful information as the cost of entry or number of courses being staged. Instead all you can learn from the BOF web site is that a lot is still TBC ...... but dogs must be on a lead !

If used properly, the new system is great. Currently however it seems we have created something that is too time-consuming for club fixtures secretaries to maintain.

This BOF project would make an interesting case study assignment for a Business school.