My take on digital project management (e.g. gallery interactive):
Clear scope, clear deadlines in defined review stage deliveries, through
iterative processes e.g. brief, concept, alphas, beta, delivery.
Success killers:
Too many 'cooks' (have a small production team, only the essential e.g.
3-4 people, if possible)
Lack of clearly defined roles and responsibilities (one person only per
role!)
Pedantic project management (rely on expertise, trust and relationships,
or to use a P2 expression: 'manage by exception')
Initial brief is gospel (possibly creativity killer no. 1)
Ludvig
Ludvig Lohse
Digital Media Manager | Imperial War Museums
Lambeth Road | London SE1 6HZ
T: 020 7091 3122 | M: 078 5443 1787
E: [log in to unmask] | W: iwm.org.uk
Visit us at:
IWM London | IWM Duxford Air Museum | HMS Belfast | Churchill War Rooms |
IWM North
On 22/02/2013 11:08, "Cristiano Bianchi | Keepthinking"
<[log in to unmask]> wrote:
>Over the past few years the software community seems to have come to
>attach totally positive values to an agile approach and wholly negative
>ones to other methodologies. Agile is the new and the future, everything
>else is old, dusty and past.
>
>We also completed a few projects in this sphere, although I yet have to
>come across a museum customer that endorses or even allow us to work
>using an agile approach. Specifications are always set at the beginning
>and everyone want to know what they are getting out of their budgets - at
>the start or near the start of the process. There is a technical reason
>agile project cannot go over budget, as the customer buys 'points' (which
>translate to man days) and establishes priorities. They would not know
>what they get at the end of the process, as as soon as the points are
>over, so is the project - unless some of the important features got left
>out and a new scope and stage is required, which necessarily involves
>more time and budget. I understand why software developers love this
>approach, as the entire risk falls onto the customer. I also understand
>that with entirely experimental work, this is a good system. What I'm not
>sure about it's that it's the only one that everyone should use in every
>situation.
>
>At the same time a waterfall approach does not necessarily mean that the
>client *must* know everything in advance, as they may not have the design
>and technical expertise to do so - but also as that would neglect the
>fact that they are working with experts in the field. As a designer and
>software developer, I feel that our role and responsibility is not only
>to execute (and especially to execute what we know is wrong!) but also to
>consult and help our clients getting the best out of their brief. In that
>respect, a project may include some budget for scoping and
>specifications. The crucial difference is when you decide what you will
>get out of the project: with a considerate waterfall, you'd know a few
>days or weeks after the start, with agile you know at the end. And that
>may not be what you wanted. Plus a considerate waterfall approach would
>have some built in contingency to make room for some change.
>
>When there is a complex project, my preferred approach would be to offer
>an initial consultation stage, for a fixed budget and set of
>deliverables, to clarify what the final result should be. At that point,
>you should be in a position to know where you are heading and can share
>the risk with your customer.
>
>Best, Cristiano
>
>
>
>> >>
>> I'm not an expert in Agile approaches
>>http://en.wikipedia.org/wiki/Agile_management but my concern over an
>>iterative approach is that it unbal;ances control of the project in
>>favour of the software expert. That may be fine, but my view is that its
>>the service provided by the technology that is important, rather than
>>the technology itself, and the museum folks are best placed to judge the
>>effectiveness of that end result.
>> >>
>> Hmm, There's many flavours of agile approaches but I really wouldn't
>>agree with it makes the technology more important than the technology
>>provided by that service or that it "unbal;ances control of the project
>>in favour of the software expert"
>>
>> In a waterfall approach its up to the client museum to come up with an
>>exact specification of what they want despite never having build one
>>before. All the software person has to do then is build it to the
>>specification - even if it turns out to be wrong. What almost always
>>happens is that once the project is built the client realises that they
>>need alterations to the specification which the contractor then charges
>>more for. So it's very usual for waterfall projects to go over budget.
>>
>> With an agile approach you set down you requirement priorities and ask
>>the contractor to come up with a prototype which fulfils the most risky
>>ones. You "the museum folks" then get to judge "the effectiveness" of
>>"the service provided by the technology" of that prototype. This is
>>particularly useful for things which are difficult to specify like "easy
>>to use" or "fun". Depending on your judgement the contractor either then
>>gets another go to refine their effort to meet your priorities or adds
>>some of the less important features. Agile approaches are less likely to
>>go over budget but you're more likely to end up dropping some of the
>>less important features because you spend the time concentrating on the
>>getting the most important ones right.
>>
>> What I think may bother Ed about Agile approaches is that it seems that
>>you need a higher degree of trust in your contractor because you don't
>>have a final list of specifications to check off at the end. My
>>experience though is that because you're asking for frequent working
>>prototypes you get much better feedback on progress than if you're just
>>expecting the final product to pop out at the end.
>>
>> Cheers
>>
>> Joe
>>
>>
>>
>> Joe Cutting
>> Digital exhibits and installations
>> @joe_cutting
>> www.joecutting.com
>> 35 Hospital Fields Road, York, YO10 4DZ
>> 01904 624681
>>
>> ****************************************************************
>> website: http://museumscomputergroup.org.uk/
>> Twitter: http://www.twitter.com/ukmcg
>> Facebook: http://www.facebook.com/museumscomputergroup
>> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>> ****************************************************************
>
>----
>
>Cristiano Bianchi
>Keepthinking
>
>43 Clerkenwell Road
>London EC1M 5RS
>
>t. +44 20 7490 5337 (Office)
>m. +44 7939 041169 (UK)
>m. +1 347 681 2471 (US)
>m. +852 9706 6581 (HK)
>m. +39 392 9939359 (IT)
>
>[log in to unmask]
>www.keepthinking.it
>
>
>****************************************************************
> website: http://museumscomputergroup.org.uk/
> Twitter: http://www.twitter.com/ukmcg
> Facebook: http://www.facebook.com/museumscomputergroup
> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>****************************************************************
>
-----------------------------------------------------------------------------------------------------------------------------------------
This email message has been delivered safely and archived online by Mimecast.
For more information please visit http://www.mimecast.com
-----------------------------------------------------------------------------------------------------------------------------------------
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
