A comment I placed on What is that beautiful house? by James Stewart on 03/10/2011
In my defence, I find it hard to write well in comment boxes and I admit my tone here has come out harsh!
After reading your points about the ‘cost’ of development, I would like to illustrate a number of the issues you will run into and the not-so-obvious gotchas you will have to manage which you have not mentioned:
– Milestone+Functionality management: You have chosen to develop a system that has many different, but interrelated (interdependant?) subsystems. This is manageable with a small and tight team, but gets a lot more difficult as soon as more stakeholders affect the direction of development (something you allude to with your paragraph on custom workflows and views on the content).
Typically, this means that the schedule of development is prone to slippage, and regardless to Agile or other methodology, there is a chance of friction between you and the people you have to report to as expected functionality and other projected milestones do not quite occur as you may have predicted.
– Scope creep: It is very hard to scope out a system that performs truly new functionality. I would very much like to see a CMS with more advanced administrative tooling as you describe but I would be naive if I thought I could guess the manner of user experience to present to even match expectation, let alone keep them from running to the hills. I would recommend extreme caution when suggesting the resources and time (NB not equivalent) required to achieve the system you plot out here.
– Bike-shedding. I cannot think of a single bespoke system I have been party to building and/or designing that has not been waylaid by this. The out-of-the-box experience of a CMS can be used as a very useful tool to define and contain these discussions – “If you want X part to change, then it will take Y time”. It supplies a useful psychological constraint against demands which is not a strongly present when a system is being created “out of nothing”.
– Ignoring existing workflows:
— pre-existing internal workflows – if I can be frank, you will discover ‘insane’ procedures that already exist for the tasks you seek to replace with your system. People will expect your system to follow the pre-existing /cultural/ workflow, even if it makes no sense.
— pre-existing ‘external’ workflows – people have become used to the idea that browsing the web is ‘idempotent’ – clicking around on blue links and using ‘back’ and ‘forward’ buttons should not change the pages they are viewing. Clicking ‘back’ 5 times should take me back to the page I saw 5 clicks ago, or pop up and warn me if not. There is a whole host of expected functionality and guidelines and it is worth pointing out that the best of these are not inventions, but they are catalogues, registries of behaviour. It is unwise to tinker with these expectations as people will not change.
There are more, but I want to move on to some important points
The system is up and running, and the development team and relationship with your overseers is well in hand. Congratulations!
– Hiring operational staff: This gets very difficult, and very quickly to, the more bespoke a system’s environment is. In short, it will raise the cost of sourcing, training and keeping staff to carry out the mundane service administration. TL;DR can strike even within job listings – I suggest that you attempt to write a short and concise description of the skills and experience required by candidates and to keep that mentally updated when your system develops. If they need to know how to calm distributed RoR setups on Heroku, Redis or AMQP backend administration and node.js server environments then this will narrow the range of candidates and increase the role salary.
Once you have found your better-than-average staff (aided by your .gov project and branding), you will have to retain them. The more skilled the staff are, the more likely they will become bored by non-developmental tasks.
This is not generally a concern within private enterprises as the means to entice and compensate staff are more flexible than with a public sector payroll.
– In-house training: As the designer, builder and maintainer of your bespoke system, you will also have to arrange for trainers, and training documentation to teach people the unique manner in which your system works. This is not something that is best to leave to this phase, as it will take time to ramp up this side of things (and no, normal documentation efforts will not be enough.)
– Expectation management: The group of people who you are working with to spec out and scope this project are not likely to be representative of the majority of the systems users, unless you have gone out of your way to ‘step over’ the hierarchy and be in contact with a broad spectrum of users. If you are adopting a phased roll-out plan, you may find quite that expectations and feedback changes in tone dramatically.