Automating a project sounds like a big task. It’s an ‘eating the elephant’ problem: don’t ever step back and look at the whole elephant, or you’ll never start at all!

Talking to several people at the recent BA2012 conference, especially to those happy few who’ve managed to achieve a good level of automation, I saw a few practical ideas emerging. This short article blends those ideas with my own experience, and will hopefully make the task look less scary.

1.       The first advice is don’t do it alone. Find some fellow-travellers within your organisation, who share your vision.  After all, it’s much more fun to work this out together. And you will benefit from a variety of viewpoints. Some hard thinking will be needed, so the right talent is important. And remember – it’s ‘talent’, not ‘resources’.

If you can, get a higher-level sponsor for what you’re doing. Even if they only give tacit approval, they will be able to help you to scale-up your ideas if they are successful.

2.       In my talk I mentioned the well-established military expression ‘ask forgiveness, not permission’. Several people came up to me afterwards and said they recognised this as an effective strategy for getting things done in their organisations. I’m not arguing here for wilfully disobeying your local standards – I don’t want to get anyone into trouble. But if you ask most large organisations to ‘choose some project automation tools’, you’ll probably spend the next 6 months deciding what ‘project automation’ is, then another 6 deciding on the perfect toolset. By which time, the definition will be out-of-date, and you’ll have moved on to another job.

So skip that stage.

Empower yourself – that’s what your company probably wants you to do.

3.       Another expression from my BA2012 talk which seemed to ring a bell with the audience was ‘good enough is good enough’. You could spend 12 months looking for the ideal toolset. If the tools will cost thousands for each user, this probably makes some sense. But the tools we’re suggesting cost a few hundred each: the same as a days work for a good BA. So use your company’s money wisely: pick some simple, cheap tools, and move on.  We’re suggesting Sparx Enterprise Architect for the main project repository, which is best used with a shared relational database - use whichever one your organisation already has. Add to this the eaDocX document generator, so that your project deliverables look sparkling, and a document repository or shared drive to put the documents – you probably have an Intranet already. If it has a wiki feature, even better: use this as a discussion forum to evolve your local standards.
Most tools have a 30-day trial (EA and eaDocX) but you’re unlikely to deliver a noticeable project in that time, but it should be long enough to get comfortable.

4.       A surprising number of people asked me after the BA2012 talk about the idea of Harvesting.
This is the idea that, to make your project repository as useful as possible as quickly as possible, you should pull-in existing information which your project can re-use straight away. This might be requirements spreadsheets, use cases or user journeys/stories in Word documents, or Visio diagrams of architectures.
These can either be attached to your project ‘as is’ (bad) or reverse-engineered so that their fine structure can be used (good). After all, you’re much more likely to re-use a requirement if it exists separately in your repository than if it’s buried somewhere in a 200-page document.
Our choice of the word ‘Harvesting’ is also very deliberate. It tries to convey the idea that there is a valuable crop of knowledge and value out there, which your company has paid good money for. All you’re doing is gathering it in, and getting more value from it. Which must be good.

5.       A key decision is your choice of an initial project.
Too small, and nobody will care about your achievements.
Too large, and you’ll get noticed before you’ve had a chance to make a difference.
Ideally, you’ll pick a project which has some deliverables which can be created from a blend of your harvested information, with your new project knowledge added-on. This way, readers can immediately start to see what you’re trying to do. You can use the EA idea of traceability (linking harvested stuff to new stuff) to show this, and carry that idea forward into the final documents. And use all the eaDocX features to show-off what else you can do, such as auto-generated appendices and glossary, with a bit of document versioning and the odd Excel chart for good measure.
This isn’t just for fun – we’ve found that, to gain acceptance of this new way of doing things, your deliverables have to be obviously better than what has gone before, not just a marginal improvement. So understand what the tools can give you, and exploit them.

6.       Finally, make use of all the project automation and tool knowledge that’s already out there. You’re not the first to do this, so preserve your inventiveness for things which need inventing.
All the tools we’ve mentioned have user groups and forums, where your peers will be happy to lend a hand. Look inside your organisation first – there are lots of ‘secret’ EA users out there, and you just might find one nearby. If not, we can also provide you with a project mentor, who can drop-in on your project for an hour now-and then via Skype (or similar tool) to see where you’re struggling. A little help like this, delivered at the right time, can keep you and your team moving forward.

So it’s time to get started. Gather your talent together, pick a project, get the tools, hire a mentor, and start automating.

(For more information and a structured approach to implementing the ideas here - see the EA & eaDocX Quick Start Programme).

Ian Mitchell. September 2012

(This is a follow-up to my talk at the BA2012 conference on ‘the 3 things I hate about being a BA’, which discussed the idea of ‘Project Automation’.)