After being involved with the CSA for the past 2.5 years, and managing the delivery of their major new online service for the past 12 months, I am pleased to say that phase2 of CSAonline has been launched. There is now an official hyperlink from CSA’s main web page across to CSAonline aimed at bringing a first stream of web savvy child support customers across into online service delivery land.

It means that Australians all around the nation can begin to manage their Child Support online. The site isn’t a full-featured suite of Child Support utilities at this stage, however the core tools are there for the majority of CSA customers. Compared to a lot of government online services I’ve seen and used, its actually quite a step forward.

Initially, I was a managing business analyst for the project, dealing with the National Directors, gathering input and putting together the logical framework of the system - what would it look like? How would the web side of things all work?. Due to the project being flagged as high on the Minister’s agenda and there initially being a shortage of web skills, once a lot of my hunting and gathering was completed, I dived in and coded up phase1 of the web application (with a full team of back-end and middleware developers to support me of course). Meanwhile, while we beefed up the web-skills shortage situation within IT - some great people were brought onto the project. Then things pretty much grew, and grew, and grew. Yep this thing was getting pretty massive. How exciting! Well it was.

Then I was handed the entire project (on the IT side of things) to manage, working parallel to a business project Director and coordinating things on the IT side to bring this monster together. We had a pile of Senior Business Analysts, Testers, Developers (middleware, back-end and web developers) and all the various administrative and helper people that you could think of. Overall there were approximately 20 people reporting to my project just on the IT side of things. The business/marketing/training side of things was another story and in capable hands elsewhere.

There was a long period of open-creativity and brainstorming. Like people overwhelmed with all the possibilities of what we could build here to really make a difference. Times were good, but not too far down the track, stress levels beefed up considerably. I was just the overseer and advisor, having moved out of any kind of hands-on role - I did pitch in with some coding towards the end when everyone was absolutely stretched. One thing I can be thankful of was having an awesome, dedicated team of people working for me and sticking loyal to me. That is really something that can make or break a project of this size.

Really though, besides some healthy stress and concern all round, things went pretty smoothly and the system was delivered on time. All right! There were some really key gun technical people absolutely totally dedicated to making this possible. People working every single weekend for a very large number of subsequent months (Are you still sure you want to become an IT professional?).

It was a project that I was really happy to be a part of, and especially to lead. Like anything sizeable that you do, there are always learnings and things that you would improve on. Not to say that these were problems, actually only dot point 4 was something that I would say needed attention. The other points were more things that I would perhaps just pay more closer attention to next time. For me, these were those things:

1. Don’t pass on the explicit actual deadline date to the technical IT staff. IT staff are wonderful dedicated people - well the CSA ones were. But somehow they always tend to stay somewhat relaxed until about 2-3 weeks before the actual deadline. This means they don’t do much overtime or stressing until the last month or so, and then they start to panic. Its noone’s fault, its just human nature I think. In future, I would have the entire team of 20 people working to a date that was 1-2 months before the “real physical deadline” and I wouldn’t pass on that real deadline to any of them. They would go berzerk working towards the fake deadline and even if things went a little over time, you would still have 1-2 months up your sleeve to tidy things up and get it 110% correct before critical launch time. You don’t want a federal Minister finding a spelling mistake or something unforseen crashing on public launch day just 2 days after the system was migrated into production! Give the team a little fake deadline. Its for their own benefit and I actually believe can prevent some of them freaking out from stress and too many hours etc. Worst case and someone is really feeling it, you can always present a “deadline extension” of a week or two to calm things down a tad.
2. User-centered design. Ok rather than senior IT managers dictating what the business or users may want. Remember, you are always building a system for the users. If a senior manager loves it, but a million users around the country aren’t fussed, then its a bad system. It can be hard, you can end up in confrontation and arguments, but you need to be firm about building a user-centered design. The best way to do this is to meet with specially selected user groups and rack their brains before you go berzerk building the system. What can we build for you? How would you feel comfortable using it? Do you understand these common web-related terms and references etc? Navigation as a keystone should always be user-centric. What as a user would I be most likely to click on most-often. Well put that as one of the main hyperlinks smack in front of a user’s face then.
3. Be sure to knock existing mainframe conventions on the head right from the start. This is something that I’ve been confronted with in half of the organisations I’ve worked in - but this is not normally an issue on smaller projects in more web savvy or flexible environments. So many old-skool dudes used to data always being in uppercase and that kind of thing. Well most certainly don’t pass any trace of this onto your users. No, your users should most certainly not have to enter their input in uppercase so that the mainframe can match it. That’s what your middleware is for - an adaptor or translator between the modern red-hot interface and the core-underlying data engine of the organisation.
4. Strike the balance between pumping sufficient fat into cost/time estimates and also not bloating things out of the water. If you pump too much fat into things, some employees will use it all up and basically spend all the allocated time to complete their tasks. A lot of the time staff will work better when under a bit of pressure. And you don’t have to take it to extremes. But when you turn a 1 day task into a 1 week task, you can virtually see energy levels relax out to an extremely comfortable level and witness not as much work being pumped out.I know, it must sound funny to hear yet another IT professional talking about the trickiness in providing the most accurate cost or time estimates. I really think you just need to double the gut feeling estimate of a competent hands on technical person or team and leave it at that. Technical people are very good at underestimating tasks simply because they know so well how to complete those tasks, they get this beautiful motion picture inside their mind of how smoothly it would all come together - but it never seems to factor in the delays that are outside of the technical person’s control, so I am saying that doubling is on average a safe bet to avoid let down in the final stages. This further reinforces my belief that the best delivery managers are always either ex-technical people or even better, current technical people perhaps only very slightly out of touch with the absolute to-the-minute latest. Look out for a post on this exact topic soon.

Overall I thoroughly enjoyed my time with CSA working on this project. They are a really great bunch of people and I think we made something really good for Australians to use that will only grow and be further improved with time.

The first thought that so many senior government managers seem to come up with in terms of online service priorities is “get that paper up online!”. Firstly, you can’t bag them out. Thesedays, even the old school senior managers are totally on board with investing in internet development. That’s great, but let’s take a step back and make sure all this effort isn’t wasted. As unfortunate as it is, sometimes its the call of a very senior government manager who makes some bold statement without having any technical understanding of the web, and all those underneath must simply follow his/her commandment - “I want all our ABC123 paper forms and letters online by July 2006!”

All key Government services are about input and output. What information do we want to collect from the citizen or customer, and what information should we display back to them. But converting an organisation’s 150 different individual letters into HTML and PDF format and listing them in a sortable datagrid is not necessarily the answer. “But W3C compliant HTML is great for accessibility, so we’re catering for accessibility, as well as supplying a nice printable, saveable PDF format.” - Spot on, but you haven’t re-thought things seeing as you now have a whole new medium to utilise to get this information out there.

Converting existing paper letters to PDF format is the quick win they all seem to get sucked into. I call these the “phase 1″ systems. They’re great, because at least you can go online and deal with Government and get the information you’re looking for.. But think about paper. Its a medium where there’s no constant reference for anyone to check - the way it works is by sending constant updates when a particular business event triggers a letter to be issued. E.g. A piece of paper arrives saying “Your child support payments have been reduced by $10 this month.” rather than the MONTHLY TOTAL field on some central web page reducing by $10 and you seeing the latest amount at any time. Great, but I don’t want a separate PDF file for every time that happens. In the paper world you would need a letter to tell you this, but on the web, why not just update some core web page. What about a single, clever dynamic web page where all my information is visible from this central hub and it simply updates and highlights when anything changes. This is exactly the type of thinking that a lot of Government departments have missed out on this time round. When the thinking has been there, however, I have seen examples of 10+ paper letter templates replaced by a single, clever, dynamic, data-driven web page. The citizen knows to check this core page, everything happens there. Problem solved and everyone wins.

Similarly, this way of thinking exists with input. They say: “Let’s build ‘web forms’ of all our paper forms”. I’m absolutely not bagging it out, because its great to be able to find every single paper form online in a streamlined web format that you can fill in and hit submit.. But this 1-1 mapping of every paper form to every new web page form is not a decent solution. Perhaps 10 forms could be combined into a new clever application for the citizin like a diary or command center for them to deal with all transactions with a particular agency. There are forms made into web pages named and labelled exactly the same as their paper ancestors. E.g. “KA01 form”. People are really going to find KA01 in the search engines aren’t they.

The worst case is that departments waste a couple of years building these “Phase 1″ secure online systems. Login to read your letters in PDF format etc. Its not the end of the world, but its just frustrating. But as I mentioned, its still progress. The only logical thing left to do after that is make the systems even simpler and better. The information is already on the web servers, just in a different structure, so it isn’t going to be as hard as this initial leap of stepping away from paper everything.

From my involvement with Federal Government, a couple of things have left me positively charged of late.

First of all, Federal Government seem to be really getting on board with RSS feeds. I know of a couple of departments working on the launch of upcoming RSS services in the not too distant future. There are already a fair share of government sites utilising RSS, but its just promising to see it spread so widely, so quickly of late, which leads me to think that its going to be a standard part of all key Government sites before too long. You know what its like with Government, once a couple of key departments have taken the leap with any given piece of new technology, the rest use that as grounds to plough ahead and do the same.

Federal Government development of key online services is alive and pumping. Its a time where the biggest, most well-funded departments already have reasonable, secure online systems in place for clients to do business with them electronically. While most of the others that haven’t are spending serious dollars to get to that position. In a few years you should be able to login to most agencies that you need to deal with as a citizen, and even authenticate through generic government portals grouped by political portfolio or perhaps even one big secure australia.gov.au hub.

To implement all this great work, I am seeing Federal Government attract more and more highly skilled technical people and become more receptive to the innovation that these workers are bringing with them. The salaries of government ICT positions have been steadily climbing for quite a while, overshadowing the remuneration of many corresponding private sector positions - and the working conditions are good. This makes these roles more attractive to skilled workers sick of working until 10pm for a proft-driven firm that doesn’t pay overtime and probably pays less money anyway.

The work going on is very promising, and as a result Canberra is buzzing with web-related activity and opportunity.