Friday, June 10, 2011

Tuning your project's GPS

[T]here are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some things we do not know.
But there are also unknown unknowns – the ones we don't know we don't know.
- Donald Rumsfeld

I'll dare to be very simplistic and state that most projects can be abstracted into 3 main stages – determination of a goal, advancement towards that goal, and completion of the goal. There's lots to debate in that tiny framework: the time-frame, the notion of “complete”, how pure the goal remains through the process, etc. but let's run with this for a bit.

Most projects start with the determination of a goal. This may be directed towards solving a problem (“People are copying music and we want to stop it”) or maybe to create/design something new (“What does the next form of online communication look like?”). Assuming it is agreed that this goal is worth pursuing, an effort is undertaken to reach that goal. In some cases the goal is not really achievable – your project is an ongoing effort to get as close to the goal as possible – but you have a direction that you're heading in. At the end of the project or at a useful point in time (say, the release of the next version) you look back and reflect on how well that goal was being worked towards. You may then continue your efforts, refactor the goal or just dump the project.

Newell and Simon (1972) described that middle stage (advancement towards the goal) as a space through which problem-solvers must traverse to achieve their goal. It is in this problem space that we often see the trouble begin.

Consider a project that you've been on recently – did you experience staff changes, political pressure, changing technologies, ideological differences, technical hitches or just anything that made the traversal go off in a different angle to what you'd expected? If you didn't then you probably ran the project in your own shed, with the door locked. If you did then the map of your traversal features a few detours, renegotiations and stop signs. Understanding (or at least generally comprehending) the space through which your project is traversing is the difference between watching your project fall from the sky like a flying piano and getting somewhere near your goal.

In their 2003 paper “The new dynamics of strategy: Sense-making in a complex and complicated world”, Kurtz & Snowden state that “we challenge the universality of three basic assumptions prevalent in organizational decision support and strategy: assumptions of order, of rational choice, and of intent”. Having thrown down (or taken up) this gauntlet, they present their Cynefin sense-making framework. This was modified slightly in an HBR piece in 2007 and makes for a useful reflection point when you just can't see the forest for the trees.

Cynefin describes four domains: Known (Simple), Knowable (Complicated), Complex and Chaotic. I find these to be useful reference points on projects as they beckon me to review the project environment and explore why things are going the way they are. I also like the fact that Cynefin isn't the same old 2x2 matrix that every second analyst seems to barrow out whenever they want to describe an optimal outcome. As Kurtz & Snowden indicate, there is no optimal state in Cynefin – you can't make everything stable (simple) and nor should you want to.

In the Known domain we see standards, well established procedures and even best practice. If we feed in input X, we get output Y and we always get output Y. In terms of technology projects, this domain invites ERP and off the shelf solutions. You probably use more traditional, structured approaches to project management, based on the SDLC.

The Knowable domain is less structured than the Known but, with the help of experts, you can find a pertinent pathway. We need to engage with the right people in the organisation to understand how and why things are. We can acquire systems that can be customised to achieve our goals and the project can be reasonably structured but we must be aware that eliciting expert knowledge is rarely a straight-forward brain dump.

Projects in the complex domain are probably my favourite. There aren't any really solid rules and you need to search for themes, commonalities and patterns as you seed ideas and check the response. In this domain there's probably not a lot of single, off the shelf titles that will meet the goal requirements. Instead you call on a mix of existing software, development, data exchange and training to work towards the goal. This, to me, is the domain in which agile practices fit well. Quick iterations, frequent demonstrations and releases, and close client contact allow the team to see how effectively they are traversing the problem space.

Chaos can be a difficult domain in which to run a project. Chaos can take form when you've suddenly dropped out of one domain due to an unplanned "happening". Maybe it's cutting edge work, a huge upheaval in the organisation, or it's a death march project taken over by a sociopath manager that has their own dream to fulfill. In operational systems, chaos occurs if your system suddenly fails (hacked, rushed/forced to production, solar flare). At this point you have to move quickly and definitively to fix the problem. Once fixed, you may be in a good position to explain (again) to senior management why you've been lobbying for that high availability setup.

To be honest I lied a bit – there's a fifth domain, disorder. You're most likely to have experienced this domain if you're a high-school teacher trying to teach VB6 to students that found a case of Red Bull in the fridge at little lunch. Being extremely agile here is the only way to weather the storm.

These domains aren't set on some dogmatic lore and you may even notice the your project spans across more than one domain. Take for example a payroll system. It's most likely in the Known/Knowable domain in terms of software but the organisational context may be Complex/Chaotic. Maybe Product X was selected but the accounting team used Product Y and look set to engage in passive/aggressive mode. Maybe you're facing an organisation with 6 payroll systems or maybe you got the budget for the software but none for the customisation.

It is important to bend your mind a bit and see if the domain really is what it appears. Perhaps what you're seeing fits the Known domain but it's really out of date and people are just clinging on to old ways – maybe it needs some disorder thrown at it. What's critical is that you get a sense of how decisions and understandings are reached within those domains. Armed with this you'll at least be able to tailor your navigational instruments as you motor towards your goal.

As someone who often works on projects that seek to introduce several new concepts to stakeholders I am often suprised that it's a struggle to convince the project office that agile methodologies are more effective than their highly structured project management framework. Everyone in the room knows that the timelines and feature-set will be difficult to set out up-front. Everyone in the room knows that we're doing more than development work - we're bringing about cultural change. But not everyone in the room likes to admit that things will get complex.

References

Kurtz, C.F. & Snowden, D.J., 2003. The new dynamics of strategy: sense-making in a complex and complicated world. Engineering Management Review, IEEE, 31(4), p.110.

Newell, A. & Simon, H.A., 1972. Human problem solving, Prentice-Hall.

Snowden, David J. & Boone, M.E., 2007. A Leader’s Framework for Decision Making. (cover story). Harvard Business Review, 85(11), p.68-76.

Wednesday, June 1, 2011

GTD® as my personal product backlog

No time to discuss this as a committee - Han Solo

I forget things - I admit it. I also look at a mass of work and struggle to know what I should do next. Part of the problem is that I have a wide range of interests and often work across a number of projects. Another issue is that I can get bogged down in the procedural if I'm not careful. My goal over the past year or so has been to organise myself so that I can better see to what needs to be seen to and give myself time to get above the forest.

I have kept lists for quite some time - sometimes on paper, sometimes using software. What I didn't really do though, was see these lists as an ongoing effort in knowing my priorities. In some ways, this xkcd comic boils down exactly what I was doing. Lists can be a prison if they're just a huge blob of stuff. This really hit home when I looked through the issue list for software that had been developed by a team I worked with. This issue list had hundreds of items, some were defects, others were features. Each week this list just rolled over and got larger. It was impossible to work out what needed to be seen to now and what was just some blue-sky thought. In the end, the development team appeared to just ignore the list and deal with issues they were being called about. My lists treated me a little differently - they made me feel guilty that I wasn't finishing everything.

So, with the idea that I could do better at this, I picked up David Allen's book Getting Things Done. David talks about many of the issues I was facing and presented a process that I find rather natural:
  1. Collect all of my stuff - emails, articles, meeting notes etc
  2. Process this stuff - work out if I need to do something and, if it takes less than 2 minutes I do it, otherwise I Organise it (next step)
  3. Organise tasks in terms of priority, project etc
  4. Review my tasks on a weekly basis to ensure priorities match my current context
  5. Work through the tasks as a series of "next actionable items"

What really hit me was the similarities with Scrum. In essence, I was drawing in my various inputs and building a personal product backlog. Each task is described much like a user story ("Book car in for service") and it's important that the task is described in a useful way ("Call John" is not as useful as "Call John about the new server order"). Each day I check my calendar for fixed tasks and then plan which actionable tasks I can achieve, based on time and priority - rather similar to a sprint backlog. Every week I groom my personal product backlog to ensure it matches my current reality.

Whilst David Allen doesn't use technology beyond pen and paper, I decided to look for software to help me organise myself. To be frank, the idea of using non-virtual folders and paper made me shudder. After a brief search I eventually chose Toodledo.  There's a fair number of titles on the market but Toodledo had plugins for the iPad® and Firefox® and I've found it flexible yet easy to keep using.

When I had an iPad I used Notability to collect things like meeting notes for processing at my normal time. The loss of the iPad (I left the job and had to hand it back) saw me go to system cards and I found that these work quite well. I would take a new card to a meeting, jot down any notes and then put the card in my in-tray for processing as any other collected item. What the card offers is a discrete input and avoids the notepad issue whereby you just end up with pages and pages of notes/tasks that never get actioned. The other thing I've been able to leave behind is the desk piled with papers that never get read and this makes my cubicle that little bit nicer.

It's not been an overnight thing and, at really busy times, I've had to focus and keep my rituals going but this has meant that I don't suddenly lose track of what needs to be done. I even get more time to think about the bigger picture.

The legal stuff:
  • GTD® and Getting Things Done® are registered trademarks of the David Allen Company.
  • iPad® is a registered trademark of Apple Inc
  • Firefox® is a registered trademark of the Mozilla Foundation