Thursday, November 10, 2005

Identify the Goal - II So why is it difficult fo...

Identify the Goal - II



So why is it difficult for a company to decide on its objectives?

It is not, I assert, because business leaders are lazy, or stupid. I truly hope this is a true statement. I propose that it is difficult to settle on firm objectives because of the infinite possibilities that present themselves for any given situation.

Let's take our example from my last entry....

Hypothetically, we are developing a strategy for a software company that is established in a relatively mature market; i.e the desktop application market. For illustration purposes, they are the number three provider of their class/type of software. They have 20% market-share. The leader in the category has 50% share. The second largest provider commands a 30% share.

So, what constitutes victory?

  • Is it increasing market share above 25%?
  • Is it attaining the number two position in the market place?
  • Is it attaining the number one position in the market?
  • Is it establishing a monopoly in the market?

    We could continue listing options, but the fact that four come immediately to mind should suffice.

    So which should we pick? I'll give you a hint; what we pick doesn't matter. Yet.

    First, we have to understand what our opponents can do, and what we think the are going to do. In military parlance, we must understand their capabilities and intentions. Once we determine that, we can pick the most appropriate definition of victory.

    And once we define victory, we can begin building a strategy to achieve it.
  • Wednesday, November 09, 2005

    Identify the goal Now, from my prior post, it may...

    Identify the goal



    Now, from my prior post, it may appear that I don't find anything useful regarding strategy development on the web. That's not true. At least not totally true.

    I think there are some corner's of the net that have very interesting work and links. Of course, context is required.

    Before we dive into game theory and its relationship to strategy, let's make sure we are all operating in the same context.

    Firstly, strategy assumes you are in conflict with another entity. This could be organized conflict, such as war or a direct competitive endeavor. It could be more general conflict such as fighting market trends. Regardless of the focus of the conflict, it is this opposing entity that you are developing stratagems against.

    Secondly, strategy implies, that you are concerned about an overall plan, not a single tactic to achieve victory. "Shoot first" is not a strategy for winning a war or battle or even a gun fight. The plans and activities that ensure you will take the first effective shot in the fight would constitute a strategy.

    Thirdly, you know what victory looks like. It is impossible to plan if you don't know what the overall aim or objective is. In the military, it might be the defeat of the opponent. But it might also be creating a state in which the opponent can no longer inflict material damage against your forces. Or it might be inflicting sufficient casualties on the enemy that they cannot entertain battle for the next generation. Knowing what the ultimate objective is, in detail, is critical.

    So let's apply this thinking to a business.

    Hypothetically, we are developing a strategy for a software company that is established in a relatively mature market; i.e the desktop application market. For illustration purposes, they are the number three provider of their class/type of software. They have 20% market-share. The leader in the category has 50% share. The second largest provider commands a 30% share.

    So, what constitutes victory?

  • Is it increasing market share above 25%?
  • Is it attaining the number two position in the market place?
  • Is it attaining the number one position in the market?
  • Is it establishing a monopoly in the market?

    Deciding what the desired outcome is, is the first step in developing a strategy. Unfortunately, for many companies, it is not so simple.
  • Thursday, November 03, 2005

    Strategy Development



    It's amazing what a quick Google Search of business strategy turns up. Where are the deep thoughts and exchange of ideas that the internet is supposed to foster? Behind a login prompt and request for payment, mostly.

    But developing strategy is not rocket science.

    Is it difficult? Yes. But only because it requires hard thinking (which we typically don't want to do).

    What makes it hard? The fact that the devil is in the details. Creating and executing effective strategies cannot be done with superficial analysis or argument by analogy. It requires real honest-to-god heavy lifting to be effective.

    And maybe that is why people want to charge for advice and services on strategy development.

    Maybe it's just because they don't want people to truly understand.

    Over the next few posts, I'd like to collect may thoughts on strategy.


    Let's start with the fundamentals. From my trusty Mac's dictionary:


    strategy |ˈstratəjē| noun ( pl. -gies)
    • a plan of action or policy designed to achieve a major or overall aim : time to develop a coherent economic strategy | shifts in marketing strategy.
    • the art of planning and directing overall military operations and movements in a war or battle. Often contrasted with tactics (see tactic ).
    • a plan for such military operations and movements : nonprovocative defense strategies.
    ORIGIN early 19th cent.: from French stratégie, from Greek stratēgia ‘generalship,’ from stratēgos (see stratagem ).

    "To achieve an major or overall aim"-- this is an important concept. If you can't state what your objective is, you don't have a strategy to achieve it. How often have you been in a business setting and asked yourself "why are we doing this?" It might just be because you don't know what your true aim or objective is.

    Thursday, June 30, 2005

    Quality Time - part 2


    So what do all these categories mean to me?

    Good question.

    One of the key areas of focus inside the Baldrige Criteria is a focus on process. Now it's easy to focus on results -- we all can measure widget sales -- but it is much harder to think about measuring processes. Let's look at an example:



    As software developers, our key value creation process is development of software. Now, how do we measure how effective our software development processes are? Cycle-time per feature? Resources per feature? Unit or acceptance tests written and passed? Lines of Code (groan)? How?

    Any of these could be "correct" answers within the criteria. The criteria only asks if process performance is measured and if those performance measures are used to evaluate improvements to the process.

    So, suppose I use unit tests written and passed versus time as one of my software development process measure. Another is features completed vs. features planned. How does that help me?

    The second part (using measures to improve process performance) is where the value is created. Continuing our example, suppose I have established that my development pace is 5 unit tests written per hour, and 98% unit tests passed. I've also complete 2 features per week and have twelve out of sixty features completed.

    Apple then release a new API such as Core Data.

    The next week my process measures may be 1 unit tests per hour but 100% pass rate. Also, I've not added any features during the week. Is this good or bad?

    Well, previously I was looking at 24 weeks remaining to being feature complete for the program ((60-12)/2). Now a week later, I'm still at least 24 weeks from completion.

    Another week passes, and now I'm back to 5 unit tests per programming hour with 99% pass rate, but I've got seventeen features complete. It looks like my projected feature complete date is now 9 weeks away ((60-17)/5).

    It looks like the week spent learning Core Data was a valuable change to my process. Additionally, if the trend on performance holds, I can move up plans for testing and ultimately delivery of my program.

    This is how process measures are used to assess and manage change.

    Of course, it is harder than my simple example in the real world ;-)

    So what does it mean for a microISV?


    The thing is, process measures don't happen by accident. They can help you make choices and improve, but you have to consciously decide to create and use them. When you use them effectively, they typically help cut through the inconsequential cruft that tends to distract us and focus. And that is the value to us.

    So, think about measures of process performance as you move into a new phase of effort for your microISV product. How will you measure the effectiveness of your blog postings in marketing your product? How will you determine how effective your overall marketing and communications strategy is? How will you measure your effectiveness at identifying and addressing customer needs? These are all important.

    And the right answers can help you stay ahead of the competition.



    Wednesday, June 29, 2005

    Quality Time




    Well, it's been a while since posting. While I'd like to say that I've been busy writing code, that would be a lie. Instead, since returning from WWDC2005 I've been focusing on may day job, including I task I signed up for earlier in the year; being a Quality Examiner for the Missouri Quality Award program.



    This process uses the Baldrige National Quality criteria to assess applicant organizations within Missouri. It's a rigorous process, and takes a significant time commitment by the volunteer examiners.



    What I'd like to do is spend a little time over the next few posts to discuss what I think a microISV (in general) and my microISV specifically can learn from the criteria.



    Before those posts begin, however, I want to parrot a project management maxim: "Quality is something you plan, not something you test for at the end." The Baldrige framework is general enough to be applied across industries and organizations of widely differing sizes. Quality is something that you need to think about as you are planning your microISV, not something you should think about as you close out your testing phase.


    The Baldrige Framework

    Leadership - Category 1
    Examines how senior executives guide the organization and how the organization addresses its responsibilities to the public and practices good citizenship.
    Strategic Planning - Category 2

    Examines how the organization sets strategic directions and how it determines key action plans.
    Customer and Market Focus - Category 3
    Examines how the organization determines requirements and expectations of customers and markets; builds relationships with customers; and acquires, satisfies, and retains customers.
    Measurement, Analysis, and Knowledge Management - Category 4
    Examines the management, effective use, analysis, and improvement of data and information to support key organization processes and the organization’s performance management system.
    Human Resources Focus - Category 5
    Examines how the organization enables its workforce to develop its full potential and how the workforces is aligned with the organization’s objectives.
    Process Management - Category 6
    Examines aspects of how key production/delivery and support processes are designed, managed, and improved.
    Business Results - Category 7
    Examines the organization’s performance and improvement in its key business areas: customer satisfaction, financial and marketplace performance, human resources, supplier and partner performance, operational performance, and governance and social responsibility. The category also examines how the organization performs relative to competitors.


    Next post: What it means to a MicroISV

    Tuesday, June 14, 2005

    WWDC Decompression

    Following the close of WWDC, I headed off to Napa for a little rest and relaxation before heading back to the paying job and full-bore development on the side. My wife and I stayed at The Old World Inn in Napa and spent a couple of days sight-seeing and wine tasting. It's been a nice interlude and given me a few minutes to place WWDC in perspective.

    Firstly, I think the switch to Intel will be good for the platform and still has some surprises for folks as the complete product roadmap and plan are revealed. Speculation on what things Intel has in store or the possibility of a multiple CPU product mix segregating the high end and mobile machines could provide interest.

    Second, WWDC was a mixed bag this year. The technical session were generally very good, but there were things that left me wondering about the overall value, as well as the commitment by Apple.
  • Technical presentations. It felt that the first two days were rehash of last years presentations and documentation reviews. It did not seem to reach a real "meat" stage until Wednesday (and for some topics Thursday).


  • Hands-On Sessions. I liked most of these, but several seemed more like a code walk-through as opposed to an instructional session. Granted, it's hard to cram as much detail as people might like into a 90 minutes session for 200+ developers, but then "Hands-on" implies a little more than a code review.


  • Keynote. Two hours scheduled, fifty-five minutes presented, and it was mostly confirming a rumor. A keynote by Steve Jobs has certain expectations. This did not live up to those expectations. Enough said.


  • Developer Systems. I get to spend $500 for my membership and $999 to lease a machine to make my code run on the next generation Mac, and a year from now, I get nothing? I'm better off financially to purchase a PPC machine that I can continue to use and operate for through 2007. Also, if you're going to announce this offer, have the details worked out so questions can be answered.


  • Campus Bash. The logistics stunk. I don't know how else to say it and remain polite. I spent just long enough in line for the Apple Company Store that I missed the music (The Wallflowers) and the food. By the time I made it inside after purchasing a few souvenirs, two of the three hours had passed, the music was over and the food was gone. I, like most shoppers, purchased Apple paraphernalia that could easily have been at a booth at the conference.


  • General Care and Feeding. It felt that wherever costs could be cut in terms of refreshments, conference materials, or attendee chachkis', they were. Many people I discussed this with had similar opinions. Overall, price remained the same, but quality declined. Personally, I expect more from Apple in the regard.



  • Finally, I do want to say that I'm glad I went to the conference, but I don't know if I'll attend next year. I think there might be better places to spend my money.



    Wednesday, June 08, 2005

    As the dust settles on Apple on Intel I can't help but think we don't have the complete picture. What is missing is the fact that we don't know what the complete product roadmap looks like. Speculation on a multiple CPU strategy depending on the client makes sense given that developers are being told in no uncertain terms to migrate to XCode. Only time will tell.

    In the mean time, I'll continue to plug away at creating some new software that will run on either architecture. But more on that later.

    Monday, June 06, 2005

    WWDC rumors and ramblings

    Okay, I guess I have to capture my thoughts on the rumor de jour:

    What makes sense:

    1. If Apple is really ready to take on MS with a x86 version of OS X, then this might make sense of the rumor. As a shareholder, I would applaud the move so long as it happens today, not next year when Longhorn will be at least close to shipping. Market data would indicate Apple has an opportunity to strike and take share of the desktop now, not in twelve or eighteen months.

    2. If there is a fork in the product line where Intel gives better performance. Since my focus is software, I can't really comment. However, the fact that Apple has significant rights to AIM architecture and the ARM processor as well, it could be a production agreement, not an architecture shift.

    3. Last year at WWDC, developers had strong interest in when cross-compilation would be a fact. The limiting factor was not technical, but the need to port OS X frameworks to x86. What if it's been done? What if XCode2.5 is a cross complier? What this would do if a subset of frameworks was enabled for x86, say for a home entertainment platform? And it might still run windows software, but safely for ma & pa?

    What doesn't make sense:

    4. A shift in architecture as the platform is starting to take off.

    5. Steve staying the course with all the "leaks" in the press.

    6. Announcing this at the core of your development efforts. Last year it was Tiger. Now, something that will require additional effort for developers to support? Not smart.

    Of course, we'll know in a couple of more hours.

    Saturday, June 04, 2005

    In the morning I'm off to Apple's World Wide Developer Conference for the second time. Last year saw the announcement of Tiger. This year the rumors did not start until two days before the keynote. The anticipation is growing as I pack and prepare. Monday will be fun and exciting.

    Starting the Blog

    I've just started my blog, following in the vein of many other programmers trying to start a micro ISV. After almost a year of part-time work on my software, I'm within sight (though months of work remain) of having a product to start talking about. This blog will chronicle my journey....