blog.RedRockResearch.com

I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public.  Our topic was Software Requirements Management.Requirements Management is perhaps the most controversial topic in software development.  Everyone seems to have their own technque.  It is also the most important skill-set–statistically more important than development skills–to the overall success of a software project (Standish CHAOS Report, 2009).Let me say that another way because this principle is not intuitive…if you want to improve the performance of your development projects, improve the skill-sets of your business analysts who generate requirements.  Statistically, this has more of a performance boost on a projects outcome than any other skill-based area.Many published requirements management techniques exists, and yet in a $220 Billion industury with a project failure/delay rate of 64%, it appears that most of these published techniques are not embraced.Our seminar covered Eliciting, Prioritizing, Validating, and Documenting a requirements baseline.  We discussed the progression of system context diagrams, UML actors, use cases, data-flow diagrams, High-Level Overview diagrams, High-Level Design diagrams and finally the Software Requirements Specification document.   We talked briefly about  a Concept of Operations document and a System Design Description document.We discussed the difference between a plan-based documentation stack, and a minimized Agile-development documentation stack–which would be generated during a Sprint-Zero.  (Yes BTW, you DO create documentation for Agile projects!)We discussed techniques to control scope creep after the requirements baseline, and then discussed techniques for dealing with what I call ‘approval noise.’What puzzles me the most about this topic is an entrenchment I encounter occasionally, as expressed by one of the seminar participants.   He stated, after the seminar, that all of this was interesting in a textbook-like manner, but that he felt none of it was pratically applicable.I asked him to explain how his company performs requirements practices and he said “Well, we have nothing written.  We have everything in our head and we just talk across the cubicles.”  He then told me he was frustrated at some additional items he was asked to add to his project that morning because it was supposed to be completed two weeks ago.  He also told me that the owner of his organization wished they had a structured approach to software project management, and that–oh, by they way–many of the programmers were given layoff notices at the beginning of the week because the company is failing.Hmm, it’s almost as if the problem is not properly in focus.  Downstream problems are caused by upstream actions or omissions.  I mean no disrespect, I just wish to point out the obvious that if companies like this would adopt upstream structure they would benefit from downstream success.You see, the problem proper requirements practices solves is not at the development effort level, it is at the project management, estimation, budget, and strategy planning–or business level.Software centric business level practices become predictable and executives can be proactive if their projects properly consume the time estimated.Projects will consume the time estimated if they include all of the functionality needed for a desired level of business value, and those functions are identified in whole, at the beginning of the project.  This way the software project time-frames and feature-sets can be included accurately in the estimation, budgeting, resource planning, and strategic planning of a company.  This way, scope creep will be minimal, and the whole company will benefit from a predictable project delivery process.Without proper requirements skills, entire feature-sets get missed upstream and need to be added ‘at the last moment’ downstream,  the risk of re-work increases drastically, and recurring cycles of this erode project managers and the development team’s credibility in the eyes of the executive team and the waiting customers.  In worst case scenarios, this can lead to layoffs and finally company failures.If you haven’t been trained on proper requirement management techniques, you are holding your organization at risk.  Attend our next three-day Software Requirements Management training course held September 7-9 in SLC.Mike J. Berry, PMP, CSM, CSPMwww.RedRockResearch.com

I was sitting in a KFC eating lunch, reading the slogans muraled 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 charish’s, 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

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

I just finished reading Good to Great: Why Some Companies Make the Leap… and Others Don’t, by Jim Collins.  This #1 bestseller is the best business development book I have ever read.  In fact–I would even say–I can recommend it with every fiber of my being.

Collins takes a team of 20 graduate students from the University of Colorado and dedicates roughly 15,000 hours of research to this book.  

Collins’s team explores why some good companies become great companies, and why the rest never do.   Their research subjects were companies that outperformed the stock market index by an average of seven times during a fifteen year span.  Their findings are novel and counter-intuitive.

The first major takeaway I got from reading this book is that great companies have learned to say “no.”  They don’t pursue opportunities that don’t meet certain internal criteria. 

The second takeaway is that achievements, although seemingly “sudden” when viewed by outside groups, are really a long set of disciplined decisions made over time by these companies. 

The third takeaway is that leaders of these great companies were not magnanimous superstars, instead they consistently seemed to have a compelling modesty about them.

A forth takeaway is that these companies seemed to consistently put their best people on new opportunities, not on their biggest problems.

Another concept Collins introduces is the Hedgehog Concept.  This concept is that companies are most successful following opportunities that have three criteria:

1. The team or corporation has a deep passion for the subject matter of the opportunity.
2. The team feels they can become the best in the world at it. 
3. The opportunity is in-line with what drives the corporation’s economic engine.

I think I could write a twenty-page review about this book.  Let me just say you need to go and read it.  If you read any business-development book this year, read this one.

Mike J Berry
www.RedRockResearch.com

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

I just finished reading Execution: The Discipline of Getting Things Done, by Larry Bossidy and Ram Charan.  This is an excellent book that examins the dynamics of making things happen inside of a corporation. 

Bossidy and Charan make a case for needing the right people, the right strategy, and the right operations in place to successfully grow a company.  They further their case by suggesting that there is a fundamental problem in business management where executives mistakenly think execution is a tactical aspect of business, and should be delegated.  They suggest this idea is completely wrong and that executives need to shoulder the task of execution at their levels.

They suggest that every business executive team should ask themselves how the company is executing and what accounts for any gap between expectations and management’s performance.

I found two very practical elements from reading this book.   The first is the importance of reality.  Good managers seek reality, and encourage their direct reports, and peers to be as realistic as possible.

The second element is an elaborate description for conducting an effective strategy review.

If your department or company is contemplating a new strategy or a new major directive, this book is a must read.

Mike J Berry
www.RedRockResearch.com

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

I finished reading Optimizing Corporate Portfolio Management: Aligning Investment Proposals with Organizational Strategy, by Anad Sanwal.  I mentioned in a previous post that this book’s forward was written by Gary L. Crittenden, CFO of CitiCorp, and a friend of mine.

In his detailing of the evolution of Corporate Portfolio Management at American Express, Sanwal makes a great case for the need for CPM in any corporation. 

He explains how real strategy is linked to investment, and how investment is really any discretionary income a corporation spends.

He presents a four-step process for implementing CPM, and in the latter part of the book, gives case studies from many large U.S. organizations that have successfully implemented CPM.

I found this book an excellent read, and a must for anyone studying the relatively new disipline of Corporate Portfolio Management.

Mike J Berry
www.RedRockResearch.com

A curious experience is looking on Microsoft’s Project Template website for ‘Software Development Project Plan Templates.’  With Microsoft being a software development company and Project being what it is, you would think there would be many software development templates–some for Waterfall, some for SCRUM, some for XP, some for Crystal, etc.

I found only two.  Both were quite rudimentary.  Interestingly enough, though, there are tons of cookie recipes, scrapbook planning templates, and other fun, useful project plans.  I was tempted to add a new subcategory for weekend jeep projects.

This sort of begs the question about how many of us are really using Gantt Charts in our software development processes.  I’ve asked my peers about it and seem to get an overall answer that ‘it takes as much time to update the gantt chart is it does to complete the project.’  Hmmm.

We used gantt charts for a while at one of my client sites, in an attempt to display project status.  Although I think the executive staff felt catered to, I got a sort of ‘deer in the headlights’ effect from them. 

An interesting side affect was that the development team discovered we could use the gantt chart, projected on the wall in all it’s glorious complexity, to underscore how busy our workload was and to negotiate for more time.  (This seemed to momentarily put us in the strongest negotiating position.)

Still searching for a better project status communication medium, I came across a wonderful process called Earned Value Management.  This is a process that developed in the government contractor circles, that displays–all-at-once–the project projected baseline for cost and progress, the actual cost, and the actual progress.  It’s a wonderful tool, and after you understand it, you would think why would we do this any other way?

Other tools exist, including Agile Burndown (or Burnup) charts–and they are helpful.  They show workload vs. schedule–two of the three series of information.  But Earned Value Charting seems to be the final endpoint for communicating succinctly the progress of your project.

Oh, btw, Microsoft Project will produce an Earned Value Chart for you.  You just need an advanced degree and probably another staff member to keep track of all the numbers it requires.  I wonder if anyone has ever tracked earned value progress on cookies baking in the oven?

Mike J Berry
www.RedRockResearch.com

We code, right!?  We code, and play Warcraft.  Why should we know or care about corporate strategy? 

Well, the answer is that most programmers probably don’t really know what their organization’s corporate strategy is.  If you do, you likely have an outstanding manager who has learned that part of their responsibility as a manager is to communicate executive directives back to Development. 

A company that performs good ‘Strategy Management’ will do two things: 

1. They will broadcast their corporate strategy to all employees so that everyone can be on the same page.
2. They will establish measurable metrics throughout the organization to determine how close everyone’s efforts are to the decided strategy.  

When this happens, an effective plan is for the Development department to adopt their own ‘Department Strategy’ that supports the Corporate Strategy.  Then look for ways to measure how effective they are at pursuing that strategy. 

For example, if your team has to report total hours for the week, reporting could be enhanced to include how many hours each programmer spends on each project.  Then each project can be placed into separate ’strategy categories.’  Then, time can be measured for each project worked on during the week, and a summary comparison can be presented to upper management showing that the Development department is ‘following corporate strategic goals’ by spending a proportional amount of time on projects that are aligned with various corporate strategies. 

If you are a manager and do this before you are asked to, you may even earn yourself a few stripes.  Kapish?

Mike J Berry
www.RedRockResearch.com