Design Authority – Part one

21 10 2007

At my presentation this year at Web Directions South I spoke briefly about the role of the Design Authority.

I’ll start this off by saying that there is in my mind, not one role that is defined by Design Authority.

There are in fact three.

The differentiating factor being the context and therefore your viewpoint.

Programme Design Authority:

This Design Authority is single point of truth for the design of a Programmes outcome configuration. Programmes deliver benefits to an organisation or entity. The projects that are children to the Programme, are responsible for delivering the capability that will deliver the benefits that are sought after by the Programme.

In the program me context, the Design Authority marshals what capabilities are required to deliver the benefits, and subsequently the outcomes from the sub-projects.

Over time, through feedback from the sub projects the Design Authority will monitor the development and the alignment of those projects with the parent capability requirements (or Capability Profile)

Enterprise Design Authority:

Similar to a Programme Design Authority, however the Enterprise Design Authority, holds a persistent or lasting role. Programmes have endings, much like projects (duh because of their implicit relationship). The Enterprise Design Authority preserves the Enterprise business intent, and provides design assurance for the programmes of work within the enterprise.

Visual Design Authority:

This is the role that is more common around the traps and would be familiar to anyone working in a development house.

The Visual Design Authority is the role that is responsible for the design strategy, as it relates to all things visual or interactive. This includes aspects like how the visual appearance evolves of a website, or what methodologies are in place for the design of interactivity or business processes, whether or not information architecture principles are applied and how and when and by whom.

Everyone needs to set up their Design Authority in the way that best suits the purpose. The term design means different things to different people, hence since I come from more than one place (being both the interface design, enterprise design space) I can see both points of view.

Why I like the concepts around the Design Authority is that it disambiguates where the assurance responsibility lies. In many contexts this role can be very useful, especially in terms of assuring alignment of effort outputs with the original vision, and in terms of providing consistency and stability in terms of visual design output and approach.

Even for small business this can be useful, because where resources are limited and time is short, wasted effort that isn’t true to the original goal can be expensive and sometimes crippling.

Within the private web development field I would even actually say that the concepts behind a Design Authority, could hold a lot of value (from a visual design authority view) in terms of a Quality Assurance Regime. Where the outputs of a development team can be independantly reviewed against the original or captured client intent, which ALWAYS looks good.

I’ll endeavor to post again about the role of the configuration manager, who enables the requirements of the Design Authority through managing the configuration of the programmes efforts.

This Design Authority role is ever expanding particularly as there is more and more rapid work or agile work being done in the software / web development space. In light of that, if you would like to pitch a question about what a Design Authority role could do for you, or if you want to comment on how you use a Design Authority already, I’d love to hear from you.





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. 





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.





Planning for User Centred Design

17 10 2006

Planning, planning planning planning.

Why? What for? don’t we just start?

Regretably no, there is a degree of forward planning that needs to exist in our work a portion of regiment. This is what is needed to get our methodology paid for.

I’ll discuss in more detail about what is needed to plan, what to plan for and all that good stuff that gets the message across.

There’s no real short answer to this either. So start reading I guess.

What steps are there in a project?
Most reasonably run projects have the following phases. (all generalisations are dangerous so think broadly here). I’ll also preface that the method described below is based upon an intermediate agile / waterfall model, which seems in the Government, to be the preferred way to operate. I’ll post more on that thought elsewhere. More agile projects have similar steps, so what’s below could be adapted to suit.

1. Initiate:
The initate phase is where all the generalised crystal ball gazing is done for a project. Wild numbers get thrown around to guess the production costs, the technical environment, and generalise the scope.

Sometimes Business Analysts get involved here too. Generally it’s involving the Project Sponsors, the Project Managers, Technical Leads, Business Analyst Leads, Design Leads, Architecture support and sometimes, key users or user reps.

2. Planning phase
This is the phase when specification baselines can be established. This is also when you can start to develop execution plans, accurate time frames, and write specifications. This is when user, task, business process analysis tasks are done.

Some technical prototyping can also occur here.

3. execute / control phase
This phase is typically reiterated in increments. Sometimes the increments can be as short as a couple of weeks. This phase is commonly called the “development” phase in more waterfall oriented projects. Development, Visual Asset Generation, testing, and other more development related tasks occur here.

Of course at the end of each increment, a release occurs.

4. finalise / release phase
This phase is largely the post implementation review phase, where final house cleaning and performance reviews are executed.

When to do design?
First up, if the projects going through its planning phase, where initial requirements baselines are being engineered by the Business Analysts, then NOW is the time to get design involved, in fact, you may already be a bit late so get cracking.

Designers work is NOT reserved for the execute phase. Business Analysts do a large portion of work during the planning phase. So should designers. The BA processes typically involve engaging stakeholders, analysing business processes, and engineering new ones. The Designers should at the same time, be conducting user research, developing profile information, developing ergonomic profiles, and drawing up interactivity specifications and so on.

So why does it get left to the execute phase to do all this work. The horse has bolted already, the BA has done their baseline, and during execute, they would be only refining them. It’s not reasonable for the Designer to come in after the main work has been done, do some research and then have to negotiate to get the process models changed?

Why not do it up front, when change is easy. Why not leverage off the BA and go on shared site visits? interview the same users or business owners at the same time?

I’ve often heard the cry “they never give us enough time to do the research!”. My question is, “Did I make it clear how much time I need, and when it needs to be done?”. My experience in the past would lead me to say “no, I didn’t”.

A mistake I’ll pass to you so you don’t do it also.

My view is that designers should be doing all the user research and specifications during the planning phase of any project. (even agile styled ones).

I also believe that designers should truly ‘design’ during this phase. Design in this context is not cutting code, or pushing pixels. It most certainly is not putting anything into development or production environments. Reserve that work for the execute phase.

Of interest I’ll be posting something soon called “Speed designing”. Which outlines how to design quickly so as to catch more, and stress less.

So what the heck should I do?
During the planning phase, the design process should be broken up into several steps.

Plan, execute, implement.

Plan:
At the beginning of the Planning phase, plan what you intend to do.
Look at the project and deliver to the Project Manager a Design Path Plan.
This plan is not the designs, or the research or anything remotely like hard work. It should simply outline to the Project Manager, what tasks you intend to use to gather information, and then actually design. The plan should also indicate how long each will take, the ordering of them, who else will be involved, and anything that might draw a cost. (Recruiting users could be considered here).

Get the Project Manager to own the document, so they should sign off on it and accept that its what they want. It’s of course up to you to negotiate it with them, but they should own it. That way they are responsible for its execution and co-ordination of it within the context of their project.

Execute:
Everything you said you’d do in the plan?…. do it.
Key points here are to get all your meetings and co-ordination done by the PM. This is important. PM’s need to manage their projects. That includes marshaling resources and co-ordinating meetings and their outcomes. If they won’t, you need to try to negotiate them into doing it. I’ll post more some time about that later.

Implement:
Remember how I said earlier that design work during the planning phase should be constrained to not specifically include asset generation?

That’s entirely true. If you get bogged down into the arduous task of generating assets in absence of the development environment, you are simply costing yourself time.

The implement part here is the final generation of the interface specifications. Plans if you will, from which you or one of your colleagues will generate assets, and which will guide the development teams through their part of the job.

If your outputs from this task are as close to possible as flat files snap shots from your high fidelity screens then your on the right track.

I’ve even successfully taken my HAND DRAWN screen layouts (drawn on my tablet pc so they can be tracked / added to word documents and so on also more on that elsewhere) and used them as endorsed specification from which development work was able to be conducted.

I could write for months about this stuff. So more later.

Good luck everyone.