Friday, May 7, 2010

Thinking. What a great idea.

I'd love to claim I came up with the title. Actually, it's an attendee comment from one of my software requirements workshops. The evaluation form asks attendees to identify the "one thing I learnt" at the workshop. The attendee went onto say that in software requirements we don't do enough thinking, and maybe if we did more of it, our outcomes would be different. A shrewd observation.

So why has 'thinking' become unfashionable in software development? Its paradoxical we live in the knowledge economy, yet thinking on the job seems as valued as much as slacking on the job. Subtly our work culture values action, doing stuff – not thinking about it. So maybe we're not doing the right kind of thinking? If we want to change the results of the work we're doing, we need to think less about what we're doing and more about the outcomes we're seeking. We can then use that idea to shape the rest of our thinking.

If we were to change our thinking, how would it change the outcomes? Here are some examples drawn primarily from software requirements development;

  • When we ask customers or users what they need, or want, the software to do – do we give them enough time to think about what they really need or want from us? What if we gave them more time, or notice that we'd be looking for input from – say in a month, rather than next week? Would the outcome be different?
  • Then, when they have thought through what they really need from us, they want to make changes and go back on what they initially told us. Do we react as if they have changed their mind? Or do we recognise that our initial request was in fact the start of their thinking process, when we were in fact hoping /expecting / wishing that their thought processes were already complete? If we'd given them more time at the outset, would the outcome be different? Would we still have gone ahead and acted upon the first things they told us?
  • When we ask for documents or products to be reviewed do we give people enough time to not just read but also to think through what they have read/observed? Do we fall into the trap of asking them on a Friday, on the hope that we will have the answer by Monday – if not that short, at least with minimal down-time for us? Would the outcome be better if we gave them more time to really review our work?

Thinking is hard work. It takes time. Yet it is hard to justify the time, not just in our overly-scheduled world, but that it just doesn't seem to fit in our project plans. We all know taking short-cuts leads to problems, but we still take them nonetheless. We just don't seem to be focused beyond the immediate.

Situations like these are challenging because we haven't thought through the outcomes we want. Instead we've focused on completing the activity, so we can move our schedule along. By doing the activity and following the process we're implicitly trusting the result will turn out right. But too often it doesn't.

To the outside observer it seems we're in fact trusting that if it doesn't make sense today – it will do by next week, next month etc. All the time, we claim we're too busy to stop and ask questions. Yet it just serves to exacerbate the siloed thinking seen in many organizations. Insular thinking in silos becomes common because we're not focused on thinking through to the outcome. If we did, we'd in fact see it represents a great opportunity to start building effective collaboration with our business peers.

Yet thinking things through before we just 'do-it' does pay off. If our goal is to improve business outcomes and results, we need to do more serious 'thinking'. Particularly if we want to improve our effectiveness and efficiency. It's not thinking about what you do, or how you do it – its thinking about the outcomes you want. Starting there and working back, the parts where we need to do some serious thinking start to be obvious.

Sounds glib, but if we want different outcomes, we need to do no more thinking.

3 comments:

  1. How does the upgrade magic work? Generally Studio tries to change repositories to their 12.1 equivalents and sometimes adds or removes few packages to ensure everything works smoothly. You can see what exactly was done in the log accessible from the bar at the bottom of the Start tab. paper rater

    ReplyDelete
  2. . IT companies on the other hand sometimes use business software for training purposes, enabling modern technologies like medical transcription. https://softurio.de/buchhaltungssoftware/

    ReplyDelete
  3. Less about what we're doing and more about the outcomes we're seeking.http://www.techbasesolution.com

    ReplyDelete