Douglas Muir - Helping Software Businesses Get The Business Results They Want

Projects:: Have we missed something ‘big’, like the ‘Business Problem’?

noreply@blogger.com (Douglas 'Doug' Muir) — Sun, 23 May 2010 20:47:00 +0000

Like you every so often I get invited to take a survey. This one was a survey of project risks. The survey author was looking to participants to help by ranking the top risks a project might encounter. All the usual suspects were on the list; incomplete requirements – check, Management might re-assign people working on your project – check, – check, and so the list went on. Nothing too earth-shattering on the author's list. However, it was quickly clear that something big had been left off the list.

The problem the project was intended to address, fix, solve etc. Not just any problem. The business problem.

Building on recent work with clients, executive and mangers get really frustrated when they feel the real problem isn't being considered. To them that's the whole point of having the project. Instead, they see the project team is completely absorbed and focused on the solution they are implementing. The unstated assumption – everyone believes that if the solution is implemented correctly, or the customer rep says it's ok then the problem has been solved.

If we're honest, we know it frequently doesn't work out like that. It's one of the reasons why many projects don't quite hit the mark – they've lost sight of the purpose – solving the business problem. It ought to be obvious, the solution and solving the problem are not generally the same.

In his book More About Software Requirements expert Karl Wiegers' gives a humorous example highlighting the issue. Some scientists asked for a new program be developed for their workstations. At their workstations they often had calculations to perform. It was a productivity issue to go back to their desks to do the calculations. The problem was analysed, various solutions were investigated by developers and their solutions costed. Investigations concluded the best way to solve the problem was not a software solution but use Velcro to attach a $10 scientific calculator to every workstation. Problem solved. The scientists were happy. Learning point; by considering the problem, and not focusing exclusively on solutions, we discovered a different approach.

Another example. One of my clients was planning a new version of their flagship software product. Several iterations of project plans were prepared that hadn't been accepted by the executives and managers. The project manager and the team felt they were doing their best and were feeling that a schedule was being imposed on them. A situation that many people will surface in any discussion on estimation and project planning. By examining the business problem it was quickly apparent that the buying cycle of the target customers was driving management's desire for a particular schedule. The outcome? Faced with a new problem, the project managers and the team were able to creatively solve this problem and deliver what was needed. A project plan that gave management and executives confidence the business plan could be solved. Indeed the team went on to do just that.

In defining a project even PMI's PMBOK doesn't bring in the need to solve the business problem. What about Agile development? Unfortunately many agile teams get stuck talking about how they're focused on delivering 'business value.' When pushed they can't articulate what that means beyond generic statements and examples.

The common thread in all these examples is the problem is viewed from either a process or solution perspective –perfectly natural for technology people. The business stakeholder sees sight of the original business problem has been lost, or worse they're left not being confident their problem will be fixed by the project.

Software types are really creative, and good at solving problem. The good news is that they can be just as creative at solving the business problem. The lesson to learn is we need to be sure that the "business problem" to be solved is not pushed aside when we start discussing the solution. After all when we're focused on solving the business problem – many of the risks in that project risk survey can be collaboratively solved.

To make sure you're not losing sight of the business problem, here are 5 points to consider:

Do you engage with your business stakeholders discussing the business problem? Do you emphasise and how the proposed solution will address their problems, or do you just discuss the business case and the features & benefits of the solution?
Does your project charter or vision document articulate the business problem or does it just focus on the business case and the solution to be implemented?
When you are estimating the project are you estimating how long it will take to implement the solution, or are you estimating how to solve the business problem?
As the project is implemented do you have regular review points such as milestones, stage gates, or sprint reviews where you can assess if the problem is on-track to be solved by the solution? Do you expressly discuss it as part of the review?
When you are considering project changes – do you consider if the project without the proposed change still solves the business problem? Do you ask if business stakeholders are willing to delay having the original problem solved, or risk the project being late, or over-budget in order to have the additional benefit from the change?

Making Software Operations Effective, Efficient :: Do Some Executives & Managers See a Gap?

noreply@blogger.com (Douglas 'Doug' Muir) — Thu, 13 May 2010 00:52:00 +0000

It's an interesting question that often crops up. Executives & Managers are continually looking for ways to improve their operational effectiveness – focusing attention on the P&L, encouraging on the business to hit the year's revenue and profit targets. Yet many overlook the connection to the operational effectiveness of their software teams.

The same issues that impact operational effectiveness impact software teams' effectiveness too;

Improving productivity
Attracting/retaining customers
Hitting "Time-to-market" (TTM)
Avoiding unnecessary expense, reducing costs
Building a flexible responsive organization

The gap between the two is more apparent in smaller, medium-sized organizations, the so called SMEs. Larger organizations have less of a problem, being much more focused on improving efficiency wherever they can. Here's an example from the oil-giant BP, in a recent Information Week article CIO Dana Deasy describes how he went about transformation their IT Organization making it more effective and efficient. Acknowledged it is a large scale example and not representative of all situations. But it highlights that to achieve operational effectiveness at the business level it is necessary to address the operational effectiveness of software teams too.

For many SME leader's a challenge they face is they don't have access to the same depth of resources and support that organizations like BP enjoy. Leaders in SME s have few resources to turn to. For most the first stop is a Google-search on the internet.

Unfortunately there's not a lot of directly applicable information available. Much information has a strong technical focus, discussing technical aspects of effectiveness and efficiency, rarely making the connection to business results. A couple of representative examples;

Mendelt Siebenga on the Agile Software Development blog discusses efficiency and effectiveness from the perspective of Agile practitioners.
On MSDN John Meier shares his advice to mentees at Microsoft on being more effective.

The information presented is technically sound in these and many other sources. The problem for executives and managers– it doesn't go far enough, falling short of their particular needs. What's missing? Simply put, the dots aren't connected to business outcomes they need.

In an SME setting it's much easier to see how the dots are connected, and even more so when they're not. So how come it doesn't help executives and managers to answer their questions? There is a gap, a disconnect. To many executives and managers what is presented to them as improving effectiveness, is really about improving efficiency.

In other words, what being effective 'means' to line managers, or practitioners is really 'efficiency' when viewed from the perspective of executives and managers.

So where does this leave those wanting to improve business results by improving the productivity and effectiveness of their software organization? It means that to take your organization to the next level of productivity and effectiveness you need start and understand where the unique disconnects are for your organization.

Identifying what is impacting you and your team's ability to deliver the business outcomes and results that you need. In future posts I'll discuss how to go about dealing with different types of gaps in effectiveness in the list at the top of this post.

Some points worth considering until then. You should reflect if your team has the resources, time, perspective and necessary independence to correctly diagnose the root-cause of the situation. Many teams are too close to the problem, frequently discounting viable solutions, or trying to second-guess what will be a palatable option for the organization, executives and managers. If you consider this a likely scenario, then as an alternative seriously consider bringing in an outside expert who has the skills to help you identify opportunities that may be just around the corner.

Identifying and solving the real problem promptly means reaping the benefits improved software operations effectiveness brings quicker.

YHURWFZFMJHB

Thinking. What a great idea.

noreply@blogger.com (Douglas 'Doug' Muir) — Fri, 07 May 2010 23:58:00 +0000

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.

Maybe you’ve just not seen it done right.

noreply@blogger.com (Douglas 'Doug' Muir) — Thu, 29 Apr 2010 23:12:00 +0000

I recently listened to a webinar with Steve Johnson of Pragmatic Marketing discussing Product Management in the Agile world. Steve speculated that the Product Owner role was created by developer's because 'maybe they'd never really worked with good product mangers before.' In other words rather than trying to fix the problems they had working with product managers, it was easier for them to create a completely new solution.

It caught my ear – Steve described a situation I have seen many times before. I see it working with clients when I'm trying to figure out the root causes of their productivity issues. I often see situations where rather than try and fix a problem, a completely new solution has been adopted. Trouble is, the new solution often introduces its' own particular set of problems. The problem has just been changed, not fixed.

Why does it always seem to turn out like this? First, it's easy to see why it happens. People often focus only on the shortcomings in what they currently do. When it comes to new solutions, ideas, they only see the upside and possibilities they represent. After all they usually don't have experience implementing it.

Second, it's only once you've started to implement your new idea, its' unique shortcomings are readily apparent. Our challenge we don't recognize new ideas are always presented in the most favourable terms – the Cinderella situation. The reality, most of our workplaces are rarely ideal – to coin a phrase used by Jennitta Andrea they are more like "the ugly step-sister" situation. In short, new ideas are more seductive than the hard work of trying to make an existing process work, or group of people deliver what you need.

Maybe they've just never seen it done right before? If they had, would they still have made such a significant change? Some might. I suspect most would try and fix their situation to more resemble what they had done right. After all –"Rip & Replace", which is what the new solution represents, sends shivers down most people.

You can avoid this. To do so you must carefully think your problem through. If you start to try and solve the problem before it's fully understood, chances are you will end up in the situation I just described.

So the next time you're considering arguing for organizational or process change consider these 7 points.

Make sure you have a handle on the root causes of the situation, not just the problem symptoms. When you get to the root causes, you'll often find the new solution you were considering is no longer as attractive.
If you are unsure if you have identified the root-causes, or if there is a lot riding on fixing the situation, consider getting a second opinion.
Consider also how the problem impacts you, your team, or your business. Is the impact felt in business outcomes, or productivity? Is it an issue of effectiveness or efficiency? If there are positive outcomes from fixing the problems, who else would benefit when they are fixed?
Also be sure to ask yourself what it will take to fix the problems. Be reasonable, realistic in your expectations. It will take time to fix something that took a while to get to this point.
Keep in mind that to do this right, you're going to be investing some of your own personal credibility in the solution. You want to put forward a solution that delivers; otherwise the credibility you currently enjoy could be impacted.
If you've convinced yourself you need a new solution – ask yourself why do I believe something I don't really know about will be better than what's in place today, and won't have its own particular issues? If you've thought it through, you're less likely to be caught out by unforeseen surprises.
Lastly be sure to ask yourself, could it be "Maybe I've just not seen it done right before"?

Introduction :: What’s this all about?

noreply@blogger.com (Douglas 'Doug' Muir) — Thu, 22 Apr 2010 22:18:00 +0000

Want to make a difference in your software business results? Whether you are an owner, leader or practitioner, my blog can help. I'll share insights I've seen improve productivity by making you and your teams more efficient and effective. I take theory and translate it into results based on my years of experience of working in the field. Avoid learning by 'trial and error' like some of the businesses that have gone before you.

Software development is all about People, Process and Tools. Follow the press and tech-websites and they'll have you believe it's the reverse; technology, processes and then people. While most people can see through the hype – people still constantly search for the 'silver bullet' – the one-thing they believe will transform everything.

Insight #1. In reality, it's all about the people. When everyone can by-and-large buy the same technology, use the same processes and practices – whether it's traditional software development or more current agile development, the part that's different – people.

Insight #2. It's what your people do, when they do it, why they do it – that makes or breaks business success. Call it alignment if you must – in reality it's about being able to 'join the dots' between the everyday things software teams do and the outcomes and results leaders want. Results come from being productive, which means focusing teams on being effective and doing work efficiently yet paying attention to the project outcomes needed.

I work with software businesses; their CEOs, leaders and their teams helping them get the business results they want. Through it I'm continually struck by how a number of small (and sometimes not so small) strategic steps in how work is done make the difference between missing and getting those results. It's unfortunate but I've come to realize that these key steps are frequently overlooked, or their significance misunderstood by many. Only after the fact, much like "common-sense", that they're significance becomes obvious – once you know. In this blog my goal is to share these insights I've found in my consultancy work to be both significant and in some cases game-changing.

Stay Tuned.