Learnings from a Major Project
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:
- 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.
- 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.
- 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.
- 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.
Tags: Consulting