© Ability Engineering Ltd. 2012

Project Automation

with

Type less, think more

Try walking around a typical IT project, especially a

business analysis team, and take a look at what

people are doing.

There’s a good chance that most are sending

emails, in meetings, or creating documents or

spreadsheets. A few will be thinking.

We think that’s wrong.

We’d like all IT people to spend MUCH more time

thinking, and much less time typing. More time

talking to the project stakeholders to understand

what they want, and less time hand-crafting one-

off documents or creating lists of issues. More

time using the knowledge of their colleagues, and

less time re-inventing it.

It’s an idea we call Project Automation. Project

Automation is about using affordable, simple

software tools to do the boring work, freeing-up

more time to do the interesting stuff.

Cumulative, marginal gains

The UK Olympic cycling team in the 2012 Olympics

won 8 gold medals out of a possible 18. No other

country won more than 1. Why? Are the Brits just

naturally better on two wheels than all the rest of

the world? Probably not. The coach of the UK

cycling team puts it down to something he calls:

“Cumulative, marginal gains”.

This means making small changes, lots of them,

and seeing which ones work. Then make some

more, and then some more. Before long, you’re

the best in the world. Not because of some huge

breakthrough, but because you make lots of

smaller changes which add-up.

This is how we feel about Project Automation. It

doesn’t come from buying a particular tool, or

implementing a ‘silver bullet’ idea. It comes from

lots of small changes, which together can add-up

to a big difference in your project and your job.

Don’t re-invent, remember

Those of you who’ve done higher degrees will

know that they start with a long, long period of

research – “what’s been done in this area, before

me?” However, the typical IT project skips this

stage, and starts inventing new stuff right away.

Finding out about ‘legacy’ stuff takes too long, and

anyway, it’ll probably be out of date.

Project Automation means spending time saving

existing work so that others can find it later, and

starting each new project by remembering that

knowledge, not re-inventing it. Sure, this won’t

deliver results on day 1, but we know it’s the right

thing to do.

Put the knowledge in one place

Before we think about saving project knowledge

for future generations, let’s concentrate on doing

our own project right.

So what knowledge will we be creating on our

project? There are the usual suspects: some new

Requirements, some new Use Cases or Processes,

maybe we’ll discover some new business rules.

Perhaps User Journeys or component models.

But these aren’t isolated fragments: they are part

of a bigger picture.

© Ability Engineering Ltd. 2012

So let’s keep that bigger picture in one place, not

as lots of separate models in different tools. We

call this bigger picture the Project Model. With a

comprehensive project model, you can start to see

how the Requirements flow into the Use

Cases,

how the Architecture affects the user

interface.

And why not also store the risks, issues and actions

of the project, who owns which requirements and

risks, who’s responsible for which actions, and the

overall “who’s who” of the project? That’s going to

be really useful for managing the current project.

Getting knowledge out

So imagine that you’ve managed to persuade your

project team to keep all their knowledge in one

place. It’s no use there unless you can get it out

again easily, for people to use. After all, most of

the dull work - which we’re trying to avoid - is

creating documents and reports for people to

read.

A key part of Project Automation is removing the

work associated with these dull tasks altogether.

This means being able to generate documents and

reports directly from the knowledge store. Sure,

you’ll spend a little time setting it up, but then you

should be able to create new versions of

documents by just re-generating them.

It also means being able to create customised

outputs for different stakeholders. In the past,

we’ve had to produce one large deliverable

document for all the stakeholders, because that’s

all we had time for.

With Project Automation, we can take a little time

to design specific documents for specific

stakeholders. This way, each one gets the

appropriate breadth of information, and the right

depth of detail. This means there’s just a chance

that they will actually read and understand what

we’ve produced!

Different deliverables for different stakeholders

Generating these documents from one model also

means that everyone gets a consistent document:

if the model is consistent, so are all the

documents. This is impossible to do for manually-

produced documents – there just isn’t time. But if

you’re using project automation, each stakeholder

gets the breadth and depth they need.

Automating the Project reports

We also suggested that the project model can

contain less glamorous information, like risks,

issues and actions.

These may not seem like first-class project

knowledge, but they are essential to making a

project work. In fact, if you are the Project

Manager, this is the most important day-to-day

project knowledge.

When the ‘main’ project knowledge is already in

your project model, then these ‘other’ ideas can

not only be kept in the same place, but linked

together.

So, rather than have a list of project issues in a

separate spreadsheet, keep each issue in the

project model, and link each one to the ‘main’

project ideas which are the subject of the issue:

So we can now produce documents or

spreadsheets of the current issues, and include

additional detail, for example, the text of the

requirement with which we have the issue. This

© Ability Engineering Ltd. 2012

makes our weekly ‘risks and issues’ report much

easier to read – all the information is presented in

one document.

Weekly reports

Project managers tell us they spend a huge

amount of time creating these lists of issues, risks,

actions etc, and then formatting them in ways

which try to give some insight into the project. For

example, a long list of requirements and their

‘created dates’ is just data.

But when it’s made into a chart:

..it shows that the number of requirements has

levelled-off. This could mean that we are reaching

the end of this phase of the project, so maybe we

can assess the risk of starting the next piece of

work now as low. This is now information, not just

data.

And if the risks and issues that have been

identified are linked to these requirements, they

can be printed out too. And all this has become

possible, just by deciding to keep all the

information in the project model, and not in lots of

different spreadsheets.

So getting ready for the weekly status meeting just

means re-generating the ‘current issues’ report

from the model, as a document, spreadsheet or

both. And, so long as the team have been

maintaining the model correctly, they don’t need

to be emailed, chased, and then emailed again to

get their latest issues. They are all there in the

project model.

Making it happen

So far we haven’t talked about specific tools, but

we hope you’re now thinking about all the

capabilities which a toolset needs to have in order

to deliver some serious project automation.

We’d like to suggest a toolset which we know will

do the job:

For the Project Model, we use Enterprise Architect (EA) from Sparx Systems.

For the document generation, we use eaDocX, an add-in for EA, developed by Ability Engineering.

Enterprise Architect (EA) for

the Project Model

We’ve been EA users for many years, and have

used it on many projects. It does all that we’ve

ever needed from a project modelling tool. It can

hold all the different kinds of project information:

Analysis models like UML Use Cases, Requirements, Process models using BPMN, as well as user journeys

Design models, using UML/OO techniques to capture sequence diagrams and component & interface definitions

Implementation models, to capture the device and platform details

Testing models, to trace through from analysis & design to the final validation of the solution

..plus all the project management knowledge, such as risks, issues and actions

…and lots of ways to connect them all together, in a way which suits individual projects.

Combined with a range of ways of sharing data

within projects and companies, and a very

reasonable pricing structure, we’ve found EA to be

a great choice. And with 300,000 users worldwide

you won’t be alone in choosing it.

MS Office Integration using

eaDocX

EA as a tool is very platform-independent. But if

your company uses Microsoft Office products

already, then eaDocX is essential.

It integrates Microsoft Word and Microsoft Excel

right inside EA.

© Ability Engineering Ltd. 2012

It allows you to design documents quickly and

simply, and then generate them directly into MS

Word. Or, if your users like Excel, you can create

Excel reports, send them out to users, and then

quickly pull their changes back into the project

model. It can also embed your EA data as Excel

charts into Word documents, and keep everything

up-to-date by a simple one-click re-generate.

This makes production of the project deliverables,

and the day-to-day reports quick, simple and

accurate.

Improving Project Quality

By keeping all your project information in EA, and

linking ideas together, you’ll start to see some real

improvements in project quality.

It will be obvious, for example, when an issue

doesn’t have an owner: it’ll be an empty space in

the Issue report, which you can use eaDocX to

highlight.

It will also be obvious when a business rule is

implemented in lots of different places: maybe

something the designer might like to fix. Or, if final

testing isn’t going well, and it’s time to de-scope

the project, you’ll be able to trace each test case

back to the requirements, and to the owner, to

understand what the impact will be.

These cumulative marginal gains are made

possible by storing all the project data in one

place, and by communicating that data

intelligently. Taken all the way through the

analysis, design, testing and deployment of a

solution, this approach builds-up to a significantly

higher-quality deliverable. Not only that, but one

which has allowed all the participants – Analysts,

Architects, Designers, Testers and Project

Managers, to all add real value to the project. And

perhaps have more fun as they do so.

Remember, don’t re-invent

At the end of this project we have a single location

for all the project information. From the business

case and high level requirements, right through to

the test results and process changes when it was

deployed. We also have the project history

captured in the status reports and formal project

document deliverables. This means that the next

project can start by remembering, not reinventing,

saving everyone time and creating quality from the

outset.

Project Automation – with Enterprise

Architect and eaDocX.

For more information about eaDocX, and to download a free, fully-functional 30-day evaluation copy, see www.eadocx.com.

For more information about Ability Engineering training and mentoring services, see www.abilityengineering.co.uk