Excellence over Heroics

I value Excellence over Heroics.

‘Excellence’ can be defined as “the crisp execution of established procedures.”  Think about that for a minute.

Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires?

The thrill of delivering when the whole company’s reputation is at stake can be addictive.  I remember once staying up 37 hours in-a-row to deliver an EDI package for a bankers convention.  I was successful, delivering the application just before it was to be demo’d.  I went home and slept for 24 hours straight afterwards.

The problem with ‘Heriocs’ is that the hero is compensating for the effects of a broken process.  Think about that for a minute.

If heroes are needed to make a software development project successful, then really something upstream is broken.

Most problems requiring heroics at the end of a project stem from improper effort estimations, inability to control scope, inadequate project tracking transparency, mismanaged Q/A scheduling, unnecessary gold-plating, or inadequate communication between the development team and the project users/stakeholders.

A well-organized development group humms along like a well-oiled machine.  Proper project scoping, analysis, design deconstruction, estimating, tracking, and healthy communication between development and the users/stakeholders will bring that excellence that trumps heroics.

Hey, I hear that Microsoft is looking for some Heroes.

Mike J. Berry
www.RedRockResearch.com

Software Production Support

In a conversation with a friend once, they jokingly described their inability to play racquetball against other seasoned players as “They are playing racquetball, while I am just hitting a ball around the room.”

I’ll borrow that reference and apply it to Software Production Support.

Is your Software Production Support group “playing racquetball,” or are they “just hitting a ball around the room?”

From a distance they can appear like the same activities.  On closer inspection however, one is much more organized, elegant, patterned, and proactive–while the other is only reactive.

Finding the order from all the choas separates the effective from the ineffective.

There are three particular areas your Software Production Support team should be focus on.  These three areas are:

1. Maintaining Systems
2. Managing Customer Expectations
3. Become a Quick-Reaction Force

1. Maintaining Systems:

Think of your production servers like a fleet of cars.  In a fleet plan, the company sends every car to get an oil change after x number of miles, a tire rotation after y number of miles, and a general tune-up, fluid change, etc. after z number of miles.  This pattern repeats itself for the life of the car that is serviced by the fleet manager.

How often are your server hard drives defragmented?  How often are the transaction-logs backed up?  How often are the indexes reindexed, and the statistics updated?

How often are memory settings adjusted for performance? Latest patches applied? How often are your servers checked to see if there any impending disk space issues?

To maximize system performance, create a “fleet plan” for your servers which checks all of these items at regular intervals.

2. Managing Customer Expectations:

If a server fails, do you know which systems depend on it? If a database goes corrupt, do you know which applications need it, and which corresponding business units will be impacted when that happens?

Do you have a way to communicate to those groups immediately?

Create a dependency map for your products.  A dependency map illustrates which servers host which databases, and then which databases are used by which applications, and finally the names, numbers, and email groups of the business users that are affected by that server/database failure.  This will enable your team to proactively manage your customers expectations.  You can notify them before they have to notify you.

3. Become a Quick-Reaction Force:

The SWAT team, the FireStation, and the Ambulance services all have something in common: they are ready to take action at a moment’s notice.

They have the information they need available to them, and additional services available with a simple call.

Do your products have support information organized and readily available?  Do you have the names and numbers of your account representative for each third-party product or tool you support?  Do you have the product-support phone numbers and your support plan credentials readily available?

Do you know who knows what about each application in your enterprise?  Who programmed it originally?  Who has supported it lately?  Which business units use it?  Where is the source code located?

Keeping information about each system updated in a central location should also be part of your “fleet plan.”

Another effective tool for a Quick-Response group is a monitoring system.  Something that indicates the overall attitude of each of your production servers?  Disk Space available? Will the system reply to a ping?  Is SQL Agent running? Is that required Windows Service up and running?  Monitoring tools like Nagios can do this for you.

Another great idea is to keep a lessons-learned log for each component you support.  Track problems, fixes to problems, assumptions to be confirmed, and ways to test if the component is functioning properly.

All of these pieces in place will make your production support much more effective.

So, think about it…is your Software Production Support team playing racquetball, or are they just hitting a ball around a room?

Mike J. Berry
www.RedRockResearch.com

The Bat-Phone

Do you have one of those executives that harasses you with status updates to projects, yet never attends the status update meetings?

Perhaps they call you, email you, stop in to your office, and want to know what the latest on project X is?

Is the behavior efficient?  What suggestions do you have about how to convey project status communication within your organization?

Mike J. Berry
www.RedRockResearch.com

Anti-Values

I was sitting in a KFC eating lunch, reading the slogans painted on the wall.  This particular KFC is supposedly the first KFC in America.  Yes, it’s in Utah.  Along with some chicken legs and a drink, you can enjoy a small exhibit showing Colonel Sander’s original briefcase, white suite, shoes, etc.

One mural read, “Somehow we’ll do it, by the principles of thrift, honor, integrity, and charity.”

I thought for a moment.  Some of the financial service companies I’ve worked with would fail if they valued charity.  Then I thought about how trust is a wonderful interpersonal dynamic, but the companies I’ve worked with in the medical field allow no latitude for trust.  Everything must be written down and authorized by a credentialed physician.  Walk into a pharmacy and you’ll need a signature on piece of paper to get a prescription filled.

Hmmm, just like charity is an anti-value in the financial services industry, trust is an anti-value in the medical industry.

I spent the day thinking about this new concept.  I owe the title of ‘Anti-Value’ to the Discovery-Channel documentary about Anti-Matter I was watching the night before.  I  guess I’m coining the phrase here, but it makes a lot of sense to me.  Normally, a value is something our society charishs, yet in a particular situation, or line of business–it becomes the wrong thing to do.

I started seeing how this concept can be applied all over to help clarify the decision making process.

I remembered taking third place instead of second in a Maryland school-district programming competition in high school because I let the guy from our rival high school cut in line in front of me to turn in his test.  When the results were announced we had both scored the same grade, but because he handed his paper in first, he won second place and I won third. (I beat him in the State programming competition the following month.)

I’ve never forgotten this experience, and actually now that I think about it, offering your competitor any leeway is an anti-value.

Some business meetings I’ve been involved in are a collage of participants cutting other participants off mid-sentence to make their point known.  Rude? Yes.  But, in fact, politeness may be considered an anti-value in these types of situations.

I think the concept is fascinating.  Just as a good value system should be in place to help an organization, department, team, or individual govern their decisions, an anti-value system can compliment a value-system by providing additional clarity for the decision making process.

One example of this is the U.S. government’s policy on dealing with terrorists.  The government values having a “no negotiating with terrorists” policy.  As a disincentive to future terrorism, they have an additional policy to provide or produce exactly the opposite of what the terrorists are demanding.  The notion–to give them what they want–really becomes an anti-value, and is an additional input to the decision-making process.  So, in fact, their policy is set by values, and anti-values.

I hope you find this concept as fascinating as I do.  It was the best $7.79 I’ve spent on lunch in a while.

Mike J. Berry
www.RedRockResearch.com

Great Mission Statements

Jack Welch, in his book, Winning, talks about how to create great mission statements.

He says most mission statements are dull, uninspired, and even unhelpful.  Most groups write their mission statement to describe only what they are in business to do.  While this is not wrong, it creates a whole bunch of mission statements that all look the same among competitors, and are not really valuable.

Welch suggests that a good mission statement not only describes what the company is in business to do, but how they are going to succeed at it.

For example, “We are going to sell lots of chickens,” is not as effective as “we are going to sell lots of chickens by growing the largest free-range chickens and advertising their value to the industry.”

Following his logic, I did some research and found some interesting comparisons:

Ford Motor Company in Europe’s mission statement (couldn’t find the U.S. mission statement anywhere online) is:

“Our Mission: we are a global, diverse family with a proud heritage, passionately committed to providing outstanding products and services.”

OK, so Ford’s mission is noble, but there is no explanation as to how they will succeed at their mission.  Compare this to Toyota’s mission statement:

“To sustain profitable growth by providing the best customer experience and dealer support.”

Toyota’s mission statement expresses their intention to make money by providing the best customer experience and dealer support.

Indeed, their mission statement tells what they are doing and how they will succeed.  This is an example of an effective mission statement.

There is a business principle at hand here:  Ambiguity is the enemy to progress.  It’s nice Ford wants to provide outstanding products and services, but there is no formula or direction given in their mission statement as to how they plan to do this.

Toyota states it will succeed by providing the best customer experience and dealer support.   Are they succeeding at this?

In 2007, Toyota became the largest seller of cars in America.  As customers, we vote with our money.  It seems then,  that they are providing the best customer experience, and are fulfilling their mission statement.

On a lighter note, Enron’s mission statement is/was:

“Respect, Integrity, Communication and Excellence.”

Mike J Berry
www.RedRockResearch.com

Book Review: Software Project Survival Guide

Posted by mikeberry | Book Reviews,Leadership,Product Management,Project Management,SDLC Management | Thursday 29 November 2007 11:21 am

In Steve McConnell’s book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.

Researching from NASA, IEEE, and some other industry giants like Grady Booch  and Tom Demarco, McConnell summarizes software development into six stages:

  1. Planning
  2. Design
  3. Construction
  4. Testing
  5. Release
  6. Wrap-up

McConnell also offers some great ideas like keeping a project history to record lessons learned and actual project data (time to completion, lines of code, etc.)

He talks about Quality Assurance practices and team development.  Interestingly enough, his book starts with a diagram and commentary on Maslow’s human needs heirachy, and how the needs of a software development group are similar.  He proposes a Bill of Rights for the project team, and a Bill or Rights for the customers.

He offers a project health quiz–allowing you to measure your project to see how probable it is at succeeding.

McConnell ends his book with a chapter on project do’s and don’t, borrowed from NASA.  These are:

Software Development Project Do’s:

  1. Create and follow a software development plan.
  2. Empower project personnel.
  3. Minimize the bureaucracy.
  4. Define the requirements baseline, and manage changes to it.
  5. Take periodic snapshots of project health and progress, and replan when necessary.
  6. Re-estimate system size, effort, and schedules periodically.
  7. Define and manage phase transitions.
  8. Foster a team spirit.

Software Development Project Don’ts:

  1. Don’t let team members work in an unsystematic way.
  2. Don’t set unreasonable goals.
  3. Don’t implement changes without assessing their impact and obtaining approval of the change board.
  4. Don’t gold-plate (don’t add features no customer asked for).
  5. Don’t over-staff, especially early in the project.
  6. Don’t assume that a schedule slip in the middle of a phase will be made up later.
  7. Don’t relax standards in order to cut costs or shorten a schedule.
  8. Don’t assume that a  large amount of documentation ensures success.

Overall, this is a great book for new software development managers, and software development mangers who have chosen SDLC, or other non-Agile development methods.  Published in 1998, this book came out before the Agile software development movement.  Regardless, it’s a good book to refer to occasionally.

Mike J Berry
www.RedRockResearch.com

Book Review: Reinventing Strategy

I just finished reading Willie Pietersen’s book, Reinventing Strategy: Using Strategic Learning to Create and Sustain Breakthrough Performance.

Pietersen first sets the stage for the rest of the book by underscoring the need for organizations to be adaptable.  He paraphrases Charles Darwin, concluding that is it not the largest, the strongest, or even the most intelligent of species that survive, but the most adaptable to change.  He explains that corporations need to start thinking beyond doing things right, to thinking about doing the right things.

He explains that vision is different from insight.  Vision is what the leader has in mind for the group.  Insight is what the group learns about their customers needs, through studying their customers.

Pietersen describes a four-step process he calls the “Strategic Learning Process:”

  1. Situation Analysis (Learn)
  2. Strategic Choices (Focus)
  3. Align the Organization (Align)
  4. Implement and Experiment (Execute)

This process provides the basic toolset for gaining insight, and turning that into vision.  Continuous learning is essential, Pietersen says, and he quotes Arie de Geus’s observation that a company’s “ability to learn faster than competitors may be the only sustainable competitive advantage” they have.

He continues, “Nature, in effect, suffers from two massive learning disabilities.  When nature fails, it doesn’t know why; and when it succeeds, it doesn’t know why…therefore strategic learning is at the heart of successful adaptation”

Pieterson’s goes on to offer a formula for initiating change.  His formula is:

D x V x P > C

D = Dissatisfaction with Current State
V = Clear Vision for Change
P = Process for Getting it Done
C = Cost of Change

His formula suggests that if D,V, or P are not strong enough to collectively overcome C, change will not occur.

Pieterson concludes his book by suggesting Strategic Learning can be applied to our personal lives to enable personal growth.  Appling it to such topics as Emotional Intelligence, and Personal Renewal, the Strategic Learning process can help us throughtout our life.

Mike J Berry
www.RedRockResearch.com

Book Review: Product Development for the Lean Enterprise

I finished reading Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It, by Michael N. Kennedy.  This book explains why Toyota’s internal product development process has enabled them to surpass the Detroit auto manufacturers production in both volume and quality.

If you haven’t heard already, Toyota now sells more cars in the U.S. than General Motors, as of 2007.  It’s also no secret that Toyota makes the highest quality cars you can buy today.

In his book, Kennedy contrasts the Detroit product development models with Toyota’s model.  He explains that the Detroit manufactures have concentrated on improving the manufacturing process by incorporating JIT (Just-In-Time) Assembly, and investing in Robotics.  He points out that although gains have been made, the Detroit manufacturer’s have really been missing the core of product development–the customer.

In contrast, Toyota has focused on the development process, not only the manufacturing process.  He explains that Toyota invests much more time up front studying customers and getting their insight about product features.  Moreover, Toyota product managers “catalog” various component options and make them available for other product managers to pick from and learn from.  Ever wonder why basically every Toyota and Lexus model car has the exact same window-up/down buttons?  This is why.

These tactics give Toyota both the flexibility and the insight to be able to deliver higher relevance and higher quality in their products.  Not only does Toyota now sell more cars in America, in terms of volume, but also has more vehicle models available for consumers.  This is a direct effect from successfully gathering the voice-of-the customer.

You can’t help but commend Toyota for getting it right.  You should always gather customer insight with any product being developed.

I think the Toyota model translates well to software development in the following ways:

  1. Gathering customer insight about a software product should be mandatory.
  2. Structuring code in re-usable formats (classes) will improve the effectiveness of the development group over time.
  3. Keeping a library of UI artifacts and ideas can help a development team make decisions faster, and have a more consistent look and feel across a large project, or across multiple projects.
  4. In the software industry, we often make the same mistake that the Detroit manufactures make by supposing quality is our final endpoint (ie: “Quality is Job One!”).  We need to understand that relevance is different from quality, and we need to structure our processes to maximize and measure relevance, along side of quality.

Mike J Berry
www.RedRockResearch.com

Book Review: Value Innovation Portfolio Management

I Just finished reading Value Innovation Portfolio Management: Achieving Double-digit Growth Through Customer Value, by Sheila Mello, Wayne Mackey, Ronald Lasser, and Richard Tait.

This book discusses implementing corporate project portfolio management by focusing on insight gained from your customers as to what they value.  I like this because I agree with their premise.  They call it the VIP approach to Portfolio Management.

This group of authors is a consultancy which has developed a methodology for gathering customer insight and applying it to their clients organizations strategy plans.

One novel offering that suggest is that while most of the industry is using bubble-charts to express strategy dynamics, they suggest using a radar-chart instead because it compares more than three axis.

The book goes on to discuss various portfolio “models” for understanding customer value in product development including Grounded, Relevant, Intentional, Optimized, Measured, Supported, Actionable, Fortified, Dynamic, and  Sustainable models.

I enjoyed reading the book and found the most valuable part of it to be their model of gaining customer insight.

Mike J Berry
www.RedRockResearch.com

« Previous Page