In Six Sigma, from what little I know about Six Sigma, you identify the outputs of your process that are 'critical to quality.' You then look to see if you can find the measures that can move those outputs. You work to drive these measures in a positive direction, quality goes up, and the requisite business benefits occur. Cool.
All this leads to process improvement.
Problem is: which process?
Lean manufacturing and the Theory of Constraints tells us that the process you pick to improve matters... a lot. If I improve a process that makes a non-key individual more efficient, there may be no effect whatsoever on the overall ability of the company to deliver value, make money, or even reduce cost. In addition, any time and effort I've invested in improving a process can, in some cases, make a person unwilling to change the process later, even if marketplace changes demand it, because "we spent all that time!"
So when you are trying to create a business case for an application, don't just say "we will make Mary more efficient." Tell the story of what Mary does, in relationship to the overall process of providing value to the company. Then it makes sense to invest in Mary. Then Mary is critical to quality. Then, any delay in Mary's job means money is spent or revenue lost. Tie it back.
Otherwise, you may spend money making Mary more efficient when a smart move would have been to give Mary a more interesting job.
I've been working on a problem that has to do with standards, enforcement, and the notion of a software development 'community' in the workplace.
As you may know, I'm a member of the IT Enterprise Architecture team. We are responsible for creating a vision of where our IT and Application infrastructure will be in five years, charting a course to get there, and then poking (hard) at the business if they want to take the easy way out and go some other direction.
That last part is called Governance: How to make sure that we all go in the direction that we all agreed to go.
We do this in our own communities. I vote for civic leaders, they pass laws (with my consent, hopefully) and I obey them. That's a democracy. Problem is: a business is not a democracy. At best, it is a benign monarchy. At worst, it is a dictatorship. But it is nearly never a democracy.
And that takes two key elements out of the loop. The folks being governed lose the right to say "who" will govern them, and the list of things they have to agree to, the laws, are not born of their concensus, but rather thrust upon them. Is it fair to call this governance?
So, in the absense of a pure democracy, how do we put back these elements: control over who and what.
One thing we are working on is creating the concept of IT communities of practice. In Microsoft IT, there are over a dozen different IT organizations that are almost completely independent of one another. So an application designer working in one group, supporting the World Wide Licensing program, for example, wouldn't normally know the name of an application designer working in the IT group that supports Microsoft Consulting Services.
So, if we group people by what they do, developers, testers, designers, architects, project managers, etc, we begin to form the 'body politic' that can become responsible for their own future.
With that body, if we can have them create self-appointed committees to determine what changes in policy that they believe should occur, then we get the beginnings of a notion of legislative power. (The problem is that a policy change that is good for a developer may be bad for a tester, and the testers won't get to know about it.)
At the center, instead of an elected administration atop a civil service, you get an appointed executive (the CIO), his appointees, and the civil service (Enterprise Architecture, EPMO, Six Sigma teams, plus others I'm not aware of). This administration has to take the suggested policy changes from the communities and decide which ones to implement.
So, do we get the voluntary compliance in this structure that we see in a democratic environment? I'm not sure. We will get more folks engaged in self-determination. But, on the other hand, I've met very few people, myself included, who think that the suggestion coming from "someone else" to tackle "problem X" is better than the solution "I'm already working on."
In other words, if the 'body politic' suggests a change, and the administration vetos it, is there an override? In a democracy, the administration is compelled to perform the will of the people, but not in a corporation. A legislative body that serves a king is about as effective as the parliment of Kuwait.
I suggest a way to get around this problem.
Tell the communities of practice the list of areas that are "off limits" for their suggestions. Define their scope in the negative, as in "You can touch anything except X, Y, and Z." Then make a committment, a real honest committment, from the executive level, that the suggestions created by one community, and accepted by all, shall be implemented in a visible manner as long as it doesn't rewire X, Y, or Z.
Effectively, this is the same as allowing municipal democracy in a centrally-controlled state (a model that I hope China will adopt, BTW, so that all those local conflicts over land use can settle down).
Can a corporation withstand the notion of municipal democracy? I don't know. I do know that the model works from an economic standpoint. Municipal democracies tend to be the most pragmatic forms of government in a democracy, primarily because they are focused on local issues (schools, trains, roads, polics, and fire, for example). It is municipal democracy that allows the administration at the federal level to focus on strategic issues, instead of being mired in the tactical. In a corporation, that is the CEO, and strategic is where we want him.
So, as we reinvent the notion of governance, where does that leave Enterprise Architecture? In the civil service.
Workflow tools only fulfill their real promise if the business users can not only see the workflow, but can modify it without calling a software developer on the phone. It has to be simple, easy to learn, and something that is difficult to add bugs. (Think Excel Spreadsheet).
Of course, the tools have to be available... something that is "safe" to put on the desk of a business user (e.g. Not Frontpage or Visual Studio)... and training has to be available. It has to be usable.
We aren't there yet... and the competition is getting close. There's a race here. Let's see who wins...
I've thought about writing a book on workflow. I have a lot to say (more below). The problem is, no one wants to read a blinkin' book on workflow. So, I'm thinking about a business novel (like Goldratt's The Goal or Who Moved My Cheese by Johnson and Blanchard). Problem is: I've never published fiction.
This is an odd space, really... business stories. Taking a dry topic and wrapping it an story makes it much easier to grasp. Normal people, who don't spend their time in geeky pursuits, may even be able to benefit (or at least, enjoy).
How else would I get someone to read a book on the notion of multiple levels of abstraction? I'm certain that a person, any person, can apply the principles of abstraction to workflow, and can create models for appropriate audiences that can be both useful and possible to automate. I'm pretty sure I can teach my 12-year-old son how to model a workflow at different levels of abstraction, and how the best way to find the "big themes" is often to reduce, not increase, the amount of detail.
It's counter-intuitive, until you do it about a hundred times.
The thing is, instead of describing workflow and abstraction and models, I'll be telling a story. And that is much harder to do.
Geeky topic: Why has there been so little investment in software cost estimation?
I know that Boehm at USC created the Cocomo model and a really cheesy and unusable tool for cost estimation. No one can understand it, and it is impossible to train a project manager on how to use it. Some products are based on this tool and they do a good job of making the interface less ugly, but the overhead for understanding the measurements is still high. (Plus I question the basic premise... that you can take measurements about things like the development team's level of experience with the code and come up with a useful estimate, when less than one third of the time on a project is spent writing code.)
Let's face it: COCOMO is a failure. It is open design (if not open source) but no one can use it.
Capers Jones suggests a different way to measure software productivity. You measure the time spent on a bunch of software development projects, across a long list of activities (things like coding, integration testing, requirements gathering, deployment, etc), and you attribute those measurements by some information about the project (like language, platform familiarity, etc. Some of the same things that COCOMO tries to turn into cost factors). You then have actual measurements. When you want to figure the cost of a project, you take the measurements for similar projects and you figure the same average productivity will exist for the new one. It's amazing effective, and quite versatile.
Unfortunately, this model requires a good bit of data about your environment. That data is hard to capture and the tools are light at best. You can make your own tool, and use published national averages, but the numbers will be suspect. Once again, there are a few niche tools, but they are expensive.
There are a couple of proprietary apps that try to bridge the gap between complexity and producing useful information. They are interesting, but REALLY expensive.
This really isn't that hard to get right... why has no one done it? A software app that is under $300 (one time fee) that can get basic information from a user, in a simple paradigm, and can construct a useful and valid software development cost estimate... is that so difficult?
If I can choose from between five different tax programs to fill out my taxes, and they all have wizards that allow me to answer simple questions, and they result in correctly filling out some REALLY complicated forms, there is no reason why software cost estimation should be as hard to do and as complicated as it is.
No wonder this area of research never took off. Mathematicians make lousy usability designers (I can say that... I'm a math geek).