Gordon P. Baty on Digital Experience

Icon

My professional opinion blog

All requirements and no concepting makes solutions dull by design

It seems to me that design processes fall somewhere on a continuum from rigorous process to chaotic and unstructured.  If you’ve been following my posts you’ll know that I’m all about smart methods that use the minimum of process and maximise adaptivity and creativity.

I’ve seen companies standardise their project management practices (clue: your company has a ‘PMO’) on a structure that includes stakeholder interviews, documentation of requirements, prioritisation of needs and so on.  I can see how this is intended to make some basic good practices systemic.  However, I think there’s a management fallacy at work here that given the right set of rules and steps anyone can run a project successfully. On the contrary, I’ve seen this approach done ‘by the numbers’ and the projects have delivered average or worse results.

At the end of the day, there’s no document or rote system that will deliver great ideas.  Original, smart concepts need space to develop outside of spreadsheets and requirements documents.  If your method is focused on creating documents, that’s what it will succeed at – but if your method is about fostering design concepts and delighting customers, it will more likely succeed in delivering strong solutions.

On a related note, don’t get too detailed on your wireframes before you’ve worked on design concepts.

 

UPDATE:  I just enjoyed this post about decision-making on iCrossing’s blog.  Makes me wonder how many formal documents are about putting an objective-appearing wrapper around choices and decisions which are quite subjective and emotional?

Filed under: creative delivery, folly, method , , , , , , , ,

Who-What-When Project Management

The formal definition of Project Management is to ensure delivery to a schedule and a budget, but the beating heart of project management (small P, small M) is to repeatedly and effectively look at What you need to do, Who are involved, and When the next actions will play out. 

‘What’ are the next activities at hand, the tasks your team members need to do, the design challenge to be addressed, the phone calls to be made and suchlike.  ‘Who’ concerns the people carrying out the tasks, the stakeholders who need to hear the decisions and updates, the downstream people who will be affected, the partners who need impressing or supporting, and so on.  ‘When’ is a blow-by-blow of how this plays out in real time and includes when conversations, actions and deliveries all take place, with an eye on which ones are dependent or parallel with each other and how they fit into a work day in a very real, pragmatic way.  

There’s no neat checklist to help you through this, or step-by-step process that does the thinking for you. The only way to really ‘manage’ a project is to be repeatedly thinking through the Who-What-When from all angles and making this method a part of your team’s DNA.

Filed under: general , , , , ,