It's probably not that easy, but it is documented. Dr. Glenn Gomes has published a set of presentation slides on strategic management on his website. The slides provide a light overview of the strategic management process. While light, they will get you thinking about strategic issues. That's never a bad thing.
Admittedly, I have very little direct experience with 6-Sigma. It reeks to me as a management fad, much like other "Quality" initiatives. I'm sure there's nothing wrong with the fundamental tenants of 6 Sigma, but sometimes it seems as if getting a couple of "6 Sigma Black Belts in the room should solve our problems!" (actual quote).
I had an interesting experience with a 6 Sigma-trained project manager once. We were getting ready to "go-live" -- that is to process data in our system. We did not have any of the connectivity ready, nor any of the automation. However, she found a loophole for calling the task done: Apparently the concept of "go live" was narrowly defined to be the ability to process data (which was complete). Therefore, the task of "going live" was done, even though at a practical level we were nowhere near that milestone.
It seems funny to me how stamping a label on these quality fads (which really seem to amount to writing down and agreeing to a project plan) immediately impresses business people.
Then again, maybe I've had a tainted experience or two.
For a final laugh, check out this screen shot. It's from a Six-sigma how-to page at the Six Sigma Guide website.
I don't want this site to just be a link farm -- I really don't. I hope to come up with some of my own useful analysis and become a thinker on my own terms. But damn it if there aren't some posts out there really worth reading. I guess I haven't cornered the market on brains just yet.
I had an invigorating conversation with a co-worker the other day. We were discussing the next generation of technologies for application component integration: Web Services and SOAA. As we got into the discussion, he made a statement to the effect that tools will help flatten out any difficult learning curve in implementing the architecture. This seems to be a fundamental flaw in thought at businesses worldwide, and thus is a worthy topic for consideration here.
What is it about software "tools" that allure? In my experience as a software engineer I have a great number of "tools" that I have had exposure to to "help" in the development process. Unfortunately, precious few actually were helpful, and more than a couple were complete disasters.
There was one tool, called Xenos d2e which was supposed to help our company mine print data so we could reformat the document with a new "look and feel" that conformed to the client's changing taste. This tool worked well enough -- given the page were static. Add too much dynamic formatting and the tool would loose track of its page markers. Of course that could be worked around by scripting code on the back end -- in REXX. Well, nobody knew REXX, so those tasked to work with this product had to ramp up quickly on the language. Then when the project transitioned to a new team the new team had to learn REXX to maintain the software. The tool was unhelpful.
Contrast that experience with a tool written by a colleague which did almost the same thing, though it was written without a back-end programming language. The tool did exactly what we needed -- to extract data from the input print stream based on defined markers. The difference? Even though the tool written by my colleague was less capable, it was designed to do exactly what was needed, took less overall time to learn and had fewer maintenance issues. This tool was helpful, and cost less on learning, maintenance and license fees.
In my current position, I deal with a certain source control package which has many integrated features and lots of bells and whistles. Unfortunately it cannot easily define multiple lines of development against a common code base, and therefore we have much difficulty in parallel development for small enhancements based on current production while doing major feature rewrites for upcoming releases. This extra management costs quite a bit of time and therefore is not efficient. And yet we gladly paid $20,000 for the privilege of being less productive than paying $0 and using Subversion, but lacking an integrated bug tracking function that we rarely make use of anyway.
Kathy Sierra over at Creating Passionate Users foresees an even more sinister issue. By hiding the implementation details, Kathy argues that we are training ourselves to not understand how technology works. One initial reaction might be that since the tool helps you get the job you want done, you don't need to know the underlying technology. This might be true for many end users, but it's extremely important for technology service providers to understand what's going on underneath the surface.
What were to happen if you suddenly had a client that was using a slightly different version of the technology? For instance, if your tool handled web services abstraction reasonably well, but your next 800 lb gorilla client used a web services handler from IBM that deviated from the standard in subtle but frustrating ways and your tool would be worthless.* If you never bothered to learn how to implement a web service without the tool, you would be stuck. Likewise if the spec was revised by the standards body and your tool's author had let the tool become obsolete. It's quite likely that your tool would limit your effectiveness in dealing with clients that had recently purchased their technology stack.
Don't let it happen to you! Use tools, sure. But be sure you know what's beneath the surface.
* I'm not saying that IBM has a deviant web services stack, but they're an easy target as their J2EE stack seems to deviate from the spec.
Michael Wade at Execupundit.com has written a short list of the reasons why most projects fail. He posits that many projects fail due to individual errors of omission. There's two things to like about this:
The contest has come and gone, and I lost in the first round. I thought I had a pretty cool movement algorithm, but apparently the bots that survived are the ones that had targeting.
An apropos analysis: You can be mobile, but you better know where your target is heading.
Productivity is now returned to normal.
We all know what Entrepreneurship is: creating new businesses from whole cloth, feeding a need in the marketplace and figuring out how to make a buck in the process.
What if you are an employee within a large company with an idea to revolutionize a portion of your business by creating a new product or service that is outside your company's portfolio of products and services? Furthermore, this idea might be outside the typical kind of business you do. Could you convince your superiors to see the value in your ideas? Could you get them to support the development of your ideas? Could you get funding, resources and time? Could you add real value to the bottom line of your company?
This is what I call Intrapreneurship -- Entrepreneurship within an existing company. Intrapreneurship is at least as hard as it's counterpart, and fails at least as often. However, it is essential to the success of the organization. Talented executives understand and foster environments that balance the necessary tasks of getting traditional work done with innovation and new business development.
Regrettably it is too common for the brass at the helm of the office to be up to their knees in tactical issues and keeping customer satisfaction high to focus on ideas that are evolutionary or revolutionary. Due to these constraints it is not possible to affect real change just by coming up with an idea and dropping it in the "suggestion box" or whatever the equivalent of that is for you.
It is therefore left to the individual contributor to develop as much of the project as can be done as a grass-roots effort before sending the project up the chain and actively selling the project to parties that might be positively effected by your idea. Find partners and advocates at any level within any group of the organization to help you develop your ideas. Two people from different functional areas making the argument for the resources to run the same project carries a lot of weight. Three is even better.
You must actively sell your idea. Develop training material, presentations and business cases, and be prepared to stop in the hallway and deliver a pitch to anyone willing to listen. Eventually (and this is, in my experience, a multi-year process) either the project will be explicitly adopted or rejected. Either way, you did your best.
Whenever I complete this process one way or the other I feel fulfilled. It is satisfying that your idea, thought up, developed, worked on and perhaps even built by you was considered carefully. Even if the idea is rejected, you know that important stakeholders and decision makers have thought about what you have to say (sometimes because you bugged them until they did). If you have done your research and pulled together a consortium of individuals to work on your project, frequently when it is not part of their regular job, you will be remembered as an effective innovator. Subsequent projects will become easier to propose, both because of the new relationships and because of the additional experience.
And eventually you'll hit a real winner. And that is when the real work begins.
I think that one of the fundamental issues at my company is the lack of adequate documentation. Although we were acquired about 2 years ago by a large multinational corporation we still run our projects "fast and loose". To help tighten up this process we should begin developing project documentation. This site has a number of project templates which I plan to use to try to build our processes.
This really isn't specifically about providing B2B services, but it highlights a number of communication issues that make working in an office environment a better place. Working in a better place leads to higher performance all around, and thus is topical to B2B services.
Read this piece on titled "Note From Boss To Employees". I think you'll find that this kind of attitude is necessary to produce a high performing team.
I just discovered something interesting: Technorati seems to believe that this site is about marketing. If you go and have a look at the tags generated for my blog, you will see that "marketing" shows up as one of the tags. What's especially odd is that, until right now, as I write this, I have never once used the word "marketing", nor have I linked to any marketing related site. Just the fact that I appear to be writing about business seemed, to Technorati, that I would inevitably evolve into a discussion of marketing.
This seems to be a bit of a microcosm, as apparently all the "business" blogs are really "marketing" blogs -- that is, they seem to describe how to market your business. Furthermore, in my industry there seems to be a massive focus on marketing, and less on the other aspects of business: customer service, project management, product management (seen at my company as a function of marketing), people management, profitability...
Undoubtedly marketing is a huge part of business, but it is only one part. I hope that writing this blog will help me to understand business more thoroughly and help me to clear my thoughts regarding business. Of course, I will from time to time speak about marketing but I would hesitate to call this a marketing blog.
My hope with this blog is to take a high-level look at the business of being a business to business service provider (an application service provider and data integration specialist, in my current incarnation) and attempt to understand how the pieces should fit together and muse about how to optimize the puzzle. Perhaps this hyper-focus of marketing is a symptom.
I have no shortage of ideas (I have, right now, 5 posts in draft, and this only after a couple of days of having the blog active). What I do have is a shortage of time. I still suffer from a shortage of experience as well. I'll bet that the last condition will solve itself in time, and I would hope that anyone with experience or hubris who stumbles here feels welcome to contribute.
This week I was given an opportunity. My boss's boss asked me to be the "project champion" for a set of features that we (the company) would like to see in our application, but that nobody has time to actually do.
I recognize this as both an opportunity and a potential pitfall. It is an opportunity because this may allow me to gain enough influence to fundamentally alter some of the brain damage we've been inflicting on ourselves for the last few years.
This is a potential pitfall because it is just as likely that this is an empty label given to a sucker who is complaining to shut him up. With the label comes extra responsibility but no authority and failure ensues.
To explore the issue, and figure out what it means to be a project "champion" at my company, I decided to write a proposal. It might be a bit of a power play to massage my job function, maybe get a budget of my own and start hacking away at the afore mentioned brain damage, but at a minimum the process of thinking about what the heck would solve this problem.
Anyway, this is just a really long way of saying that I did a Google search for "project champion" and found notes from a course on software project management by the University of Glamorgan in the UK. Many of the principles there will be old-hat to anyone involved in software projects, but there are good sections on development methodology, planning and some of the corporate-political aspects of project management.
I just added Joel Spolsky's blog RSS to my sidebar. This wouldn't be a newsworthy event except that I really want to draw attention to his success. He's a software engineer now managing a software company (Fog Creek) which seems to make some pretty popular products.
He also has some really radical-sounding ideas on how to run a superb software company. Interestingly, most of those ideas boil down to the following arguments:
I just learned that my company is sponsoring a JRobots contest for the software engineering staff (of which I am a member). This is probably one of the best, and yet worst, team building events I've heard of. I mean, we're good at programming, but who wants to drudge through coding work crud if you could be programming a 'bot instead?
I predict reduced productivity through the contest end.
BTW: There is a substantial prize for winning. Anyone have a strategy suggestion?
Companies frequently claim they are seeking success. What is success? Most of the time and to most people, success equals making a ton of money. I think that is a rather narrow approach to success. Let me offer a different definition of success, one that is particular to B2B service providers.
Success is when significant value is created for all parties.
Profound, no? This means that your success as a service provider is directly tied to the value you create for your client. Furthermore, you have a vested interest in making sure you are providing the right service and the right product. And you also must understand that you must price to create value for yourself too. Perhaps this really ought to be obvious, but all too often we fall prey to one of the pitfalls mentioned below.
All too often there is a temptation to offer extended value for the client. This usually manifests itself as undercharging for services, or waiving service fees for value-added services. This can also be by overzealous sales staff promising what cannot be economically delivered. I'm working with a client now which is getting nearly all their services free, yet is extremely unhappy with us. Why? Because somewhere along the way, they feel they were promised services we don't normally render. When we came back to them and suggested that they might pay for these services, they escalated, and now we are giving them a number of services which are outside our scope of expertise. On top of that, some of these services we have not had great success in implementing, probably due to other kinds of incomplete communication of requirements, which compounds the client's unhappiness.
All of this sounds terrible, but reading until now, you might yet see opportunity for success. Not entirely! You see, part of the sales process assured the client their existing processes would not be impacted. So, the client's desire was to replicate their process work flow using our tools. Unfortunately, our system is not a work flow modeling system, and as such cannot easily accommodate deviations in the preprogrammed work flows. This leads to some very weird procedural hacks that the client must remember to do "just right" in order to replicate their processes. I think that while the client may get the system working, it will never be as successful as is possible.
Another counter example of a value equation gone wrong is when the vendor manages to capture the majority of the value for themselves. A few years ago I worked for a company that had adopted a new tool to assist in development of its core product. In fact, this tool really wanted to replace the programming staff. While this might be a laudable goal, the tool fell short on several counts. Management, however, persisted in requiring its use because the vendor had negotiated an agreement by which they were paid a minimum usage fee for a fixed period of years. That's right -- management had literally locked themselves into a net-negative value deal, and instead of eating the (rather large) fixed amount, they opted to persist in using the tool hoping that additional experience would make the warts disappear. The vendor had literally made it too expensive to not use the tool, and they had no incentive to improve the tool as the payments were fixed in a long-term arrangement.
So how should this process work? In a perfect world, I would like to see a discussion of what services can be provided, and for what reasonable costs. This discussion should include a complete review of the current business processes, and a mapping and gap analysis of business process to tool capability should be created. No more should wacky process hacks be allowed to gum up what would otherwise be a much more efficient system. The question "Why do you need to do that?" should be asked frequently. Answers to this question frequently show an underlying deficiency in an existing process which, when resolved, increases overall efficiency, increases value and locks in long term success.