Capability profiling – quickly – cheaply – for small sites.

3 10 2007

Good evening everyone!

Diving straight in, Capability profiles.

These are a fantastic little doodad which are very very useful for figuring out what a project has to deliver.

Often I’ve found myself starting off a project, and jumping straight into outcomes as derived from a vision statement.Something like this:

Vision: “We want a better online presence to improve the front end of our business.”

Outcomes: “well, lets build you information pages, and build in a blog, with an events calendar….” and so on.

But there is a critical step in there that often gets missed.

And it’s fiendishly easy to do, and very very valuable.

A capability profile is a set of statements, which can describe in plain English, almost conversational terms, what capability is needed once the project is done.

Eh?

Well, my learned friends a capability profile would look something like this for a fictitious company.

Capability profile

For: That Company over yonder.com.

1. Ability to be able to offer time limited sale opportunities to our clients.

2. Ability to be able to offer special online services to a member group.

3. Ability to manage that membership group, and send out email offers and other sales or marketing materials.

4. Ability to maintain the content and page structure ourselves.

5. Ability to have a photo gallery of our products.

6. to have purchase oriented transactions be performed through the site.

And so on….What this gives you as the developer / designer / whatever, is a really useful communications tool to use with your client to help them define exactly what the site is going to do.

worksheet-demo001.png

But absolves both / all parties of needing to look carefully into what is going to be built exactly.

In Agile managed projects (and waterfall ones for that matter), the capability profile can be used as a single point of truth, owned by the Design Authority role (see my slide share on Natural Project Management With Notes or Without Notes)

Now, clarity around what the end state capability should be is really useful in a financial sense as well, becuase particularly with Agile developments, having clarity of vision can really save the development team a lot of money and time.

I should note as an ending statement, the capability profile is NOT a static document, and should be reviewed by both the project team and the owners at every iteration.

Particularly in an agile development, because as we all know, because agile is so powerful new desires for more capability come up ALL the time.

To support anyone who is interested, I have a neat little set of .PPT / .KEY worksheets and a workshop agenda process which are great to use to help work through the development of your capability and outcomes profile.

If you’d like to get your hands on it, drop me a line!





Web Directions South 2007

29 09 2007

Waterfall and macbook pro 

Well what a show!

Big show everyone, I had a fantastic time socialising and learning and getting all inspired by the amazing array of quality presentations.

I’ve taken the opportunity to post to flickr update profiles, get a twitter account and post up a slideshare of the slide pack WITH NOTES for anyone interested in what I was discussing.

For those of you who either didn’t get the chance to attend, or had questions or comments, please feel free to contact me via my facebook or twitter or even the old fashion way if you have my other details.

I’d be more than happy to discuss the issue of agile and waterfall integration or lack there of, or anything really if it will open up the gates for getting more success to those who need it.

Thank you once again for everyone for your comments (plus’ and negatives) they all go to a good cause…. not making the next presentation painful. 





Agile teams poised for success

1 11 2006

I wrote before about agile projects.

Big topic. Plenty of far more authoritative material around than I could ever write about.

But what I take from it, which is often what I write about is the behaviour of it, in various applications.

Here’s a different application for you.

Teams can be agile too.

Teams in my experience, irrespective of size, get too often caught up in over engineering processes.

Who’s heard this one?

“I need our team to be able to have redundancy built in should people leave. Therefore, we need all our processes documented and stored”.

I see from that exercise little else except pain and suffering, and a massive overhead in administration.

Now, the key point here is that I actually support documenting processes. As a manager, you need to have redundancy built into your tactics catalogue, because your team won’t always be there. Hell YOU may not always be there!

In the past, I actually wrote up some processes which had the following things:
– title
– scope statement
– change control panel
– authorisation blocks
– impacts
– external factors
– technology requirements
– implementation specifications
– background statements
– and so on.

Now, for major procedures this level of depth and rigor may have been appropriate, or for major teams (call centres and the like, where it would be warranted to handle procedures this way).

For the majority of teams though, where turn over is less of an issue, and where cultural learning and procedures may be more effective, I’d suggest the following:

Engineer less, record more:
Is there something wrong with giving the process a simple name, drawing a simple diagram with some words on it, and then saving it to your group drive / web space / something?

“oh but it looks bad!”

I don’t care. Process mapped, saved and available. less than 1 hour. Low cost. cheap to re-do. Easy to read, easy to edit.

Over-engineering is a great way to make something look really great, but make it utterly ineffective.

This thinking can be applied to many facets of a teams operation. Not just how the procedures are written.

Think about applying the less is more concept to specifications. How about to communications? Reporting? something else?

I guess the underlying thing here is you don’t ALWAYS have to have everything looking great and perfecto. Look at my posts! they are unstructured and would make most editors gag and choke then email it to their mates to have a bit of a chortle.

I get the last laugh, I can write quickly, change things quickly, meet needs and be timely. And my approval process doesn’t infuriate me with endless refinements and changes.

Some might call it wishy washy. I call it agile and lightweight. It lets me get more done.

I’ve found that responsiveness of myself and my team is valued more than having elegant procedural files.

By the same token, I have to be responsible and engineer when its needed, and draw when its not.

When I’m in doubt I always fall back on old reliable.

What’s actually needed by my end users?





Agility, backflips and what not.

1 11 2006

I had a tremendously good conversation with an old colleague today. He’s heavily involved in this massive change the world style project.

He’s just the guy who I think could pull it off too. He’s a strong leader, possesses vision, is charismatic and people want to follow him. Plus he has a sense of humor and a genuine desire to improve the world.

I got to thinking about the project he’s working on. The scope of which is almost unimaginably huge. So huge, I think it’s quite revolutionary what he’s doing. I cant disclose much detail about the project at this point as I have no authority to do so. Perhaps later I may, we’ll all see.

Anyway, I was thinking that because of the size of the project, it’s a significant risk that the project will encounter what I call “big project stuckinarutism”.

Having worked on projects ranging from several thousand dollar mini sites right through to several million dollar content management system installations, I’ve learned something. (big big issues if I hadn’t hey?)

Projects are like a chocolate cake. Little ones can have have all sorts of toppings on them, because you only need a little bit of topping. They can be eaten quickly when no ones looking, and they are well and truly gone before anyone knows it was ever there.

BIG cakes however need plates, and big knives to cut them. Toppings are expensive, and you have to think very carefully before you pick your topping, or else you’ll waste a lot of money having to re top the cake. You can’t snake a piece of the cake without someone knowing, nor can you scoff the whole thing either.

So before you “option ‘Q'” your way out of this blog i’ll get to the point.

Big projects can suffer at the hands of their own mass. Change of direction is hard, planning is complex, specifications are complex AND hard, the list goes on.

How do you fix this? Well old school managers and strategists could possibly theorise this:
– Use a waterfall PM technique. That way you can have a nice rigorous predictable project path flow.
– Specify the project scope and requirements heavily prior to commencement, that way you minimise risk of heading off on the wrong path.
– Plan your phases in neat time boxes, with well defined parameters and milestones.

You get the drift. (A familiarity with commonly practiced project management techniques is assumed here)

Can large projects be agile? Will the concept work?

I think so, but the catch, as with any implementation of an agile project, is that it must must must have a strong leader who understands how the agile / iterative approach works, how to manage it, how to feed it, and how to control scope of a highly liquid operational behavior.

Big ask really. Do-able, but big.

What’s the trick? I’d suggest firstly figuring out if your users actually want a chocolate cake. Start there.

Then, see just how big that cake needs to be. Presuming you need a very very very big cake, see if you can meet the same need by making smaller cakes from the same batter.

Of the smaller batches of batter that you now have, see if they can be prioritised so that you can cook them in batches, because you can only fit so many cakes in there can’t you?

Of course you could iterate that last step to make smaller and smaller cakes.

As you get into making smaller and smaller you increase your ability to have more and more agility in your project.

Again, I have to reinforce this point, I’m generalising, and there are lots of if, buts and maybes surrounding these statements. But at least I can give you the gist of it.

Agility in projects, and teams, is a big topic. I’ll publish more over the fullness of time.

Your users may not want big chocolate cakes, they may want banana muffins. Ask and ye shall find out.