Recently David Crossett of Ready Receipts gave me a great tip.  He told me that instead of going to your local OfficeBOX superstore and paying $200 for a 4×8 whiteboard, just hit HomeDepot instead and get a $12 piece of showerboard.  It works just as good and if you need a smaller size they will cut it for you on site for no additional charge!  At that price, you can line your walls with thinking space.  Power to the Consumer–thanks David!

Mike J. Berry
www.RedRockResearch.com

Follow www.twitter.com/RedRockJobs and be the first to know about immediate tech job openings, contract work, side jobs, or special requests.

You never know when that friend in need could be you!

Mike J. Berry
www.RedRockResearch.com

Moore’s book is a must-read for any IT company trying to launch a new product.  Although the concepts in the book are not novel (so admit’s Moore) the book brings a vocabulary and metaphoric dictionary to the readers allowing marketing groups, investors, and techies alike to communicate about the playing field in a proactive manner.

Moore discusses the importance of delivering continuous innovation, instead if discontinuous innovation.  Our new innovations need to help people do what they are already doing better, and not force them to abruptly change something that kinda works for something that they are not sure about that may possibly work better.

Moore introduces the Technology Adoption LifeCycle, complete with five categories of market segments.  He discusses how to market in succession to each group:

1. Innovators
2. Early Adopters
3. Early Majority
4. Late Majority
5. Laggards 

Finally, Moore introduces some business concepts you may have heard of by now, like the bowling alley, the tornado, and the fault line.

If you haven’t heard of these, then you need to get reading!

Mike J. Berry
www.RedRockResearch.com

Quality management, that is, in the sense of improving software processes and production support methods, not about ‘how to test software.’

I include overviews of the four formal quality models: CMMI, Six Sigma, and ISO 90003, and ITIL.  I outline how to create a quality system within an organization and I discuss common fixtures it should have.

I talk about checklists, measurements, purpose, accountability, and continuous improvement.

So now I want your help.  Tell me what else I should include in a book about managing quality in an IT/Software Development/Production Support environment.

Also, suggest some titles.  Thanks in advance!

Mike J. Berry
www.RedRockResearch.com
 

I like Asian philosophy (and swords and such) so I picked up the book and read it.  The book was written in 1643 by an undefeated Japanese samurai master who was so effective he was rumoured to have spent the latter part of his career entering sword-fights purposely without a weapon.  Although meant as a battlefield manual, the book has gained popularity as a handbook for conducting business in the 21st century.

The book was translated into English by Thomas Cleary at some point and the edition I read was published in 2005.   Improperly named “The Book of Five Rings,” the book is actually a compilation of five scrolls.

The Earth Scroll: Musashi talks about how a straight path levels the contours of the Earth and how various occupations provide life-improving principles.  He talks about observing patterns and learning from them.  Certainly a great primer for any business trying to get across the chasm.

The Water Scroll: Here Musashi talks about how water conforms to the shape of its container.  He suggests a separation of one’s inward mind against it’s outward posture, maintaining that one’s control over one’s mind must not be relinquished to outward circumstances.  He translates these philosophies into about 80 pages of sword fighting techniques.  An interesting modern parallel is found in Jim Collins book, Good to Great, where he talks about how the most successful companies are able to say ‘No’ and not be influenced by immediate but non-strategic opportunities.

The Fire Scroll: As with any book written by a 16th century samurai master, you’d expect a core discussion on combat strategy.   The fire scroll is full of combat strategies, positioning, and pre-emptive theory.  Very interesting.  Did anyone notice how Apple’s announcement of the latest iPhone came about 1 day after the Palm Pre phone was officially launched–killing it’s market blitz?  No coincidence there.

The Wind Scroll: The wind scroll contains a directive to study and be aware of your opponents techniques.  Translated into business speak, this means one should always study ones competitors.  Be aware of new offerings, partnerships, markets, etc. that they persue.  Emphasis is placed on observing rhythms and strategically harmonizing, or dis-harmonizing with them as appropriate.

Finally, The Emptiness Scroll:  This scroll discusses the value of escaping personal biases.  Emphasis is placed on not lingering on past situations and being able to adjust quickly to new scenarios. 

Overall I found this book ‘enlightening’ to read.  If you like metaphors and inferences, or sword-fighting, then you will enjoy this book. 

Mike J. Berry
www.RedRockResearch.com

We covered the typical informal methods: Fuzzy Logic, Wide-band Delphi, Planning Poker, and the primary formal methods: Function Point counting, the Putnam Model, COCOMO II, and COSMIC-FFP.   We also discussed how to estimate the percent of defects still in your application at the time of release.

Along with ‘how’ to estimate software projects accurately, we discussed how to manage the expectations of the executive team and the investors who typically want everything now.  Chris Perry, from the Utah iEEE CS chapter was in attendance and said “All the things your talking about I’ve been living for the past 10 years!”

Join us this Thursday, July 16 for our 2-hour seminar on Software Requirements Management.  The cost is only $10!

Mike J. Berry
www.RedRockResearch.com

This is basically a summary of my three day courses that I am now offering.  I’m giving the info away to get some attention in the valley.  Each workshop is from 3:00 - 5:00pm Thursday afternoon at the Miller Campus - Professional Development Center  This represents a tremendous value as I have put over 3000 hours of research into the material and consumed over 100 industry books.

Topics

Software Estimation - July 9th

Software Requirements Management - July 16th

Software Quality Systems Management - July 23rd

Software Development Life Cycle (SDLC) Management - July 30th

Event Calendar and Info

http://www.utahtechcouncil.org/Events/Community-Events/Community-Calendar.aspx

Hope to see you there!

Mike J. Berry
www.RedRockResearch.com

Lawrence Putnam presented this model in his 1992 Book titled Measures for Excellence.  His book reads more like a math text than a software development guide, and suffers from an unfortunate formula typo which has lead to widespread confusion about his models in the industry, but I will  explain his defect removal rate calculation process.  (I hired a math wizard to examine his data and correct the formula!)

1. For a typical project, code is produced at a rate which resembles a Rayleigh curve.  A Rayleigh curve looks like a bell curve with a long-tail.  See my ASCII graphics below:

        ||||
    |||||||||||
 |||||||||||||||||
|||||||||||||||||||||||

2. Error ‘creation’ typically happens in parallel and proportional to code creation.  So, you can think of errors created (or injected) into code as a smaller Rayleigh curve:

        ||||
    |||+++|||||
 ||||+++++|||||
||||+++++++||||||||

where ‘|’ represents code, and ‘+’ represents errors

3. Therefore, as defects are found, their ‘detection rate’ will also follow a Rayleigh curve.  At some point your defect discovery rate will peak and then start to lesson.  This peak, or apex, is about 40% of the volume of a Rayleigh curve.

4. So, when your defect rate peaks and starts to diminish, factor the peak as 40% of all defects found, then use regression analysis to calculate how many defects are still in the code and not found yet. 

By regression analysis I mean if you found 37 defects at the apex after three weeks of testing, you know two things:  37 = 40% of defects in code, so code contains ~ (37 * 100/40) = ~ 93 errors total, and your finding about 10.2 defects per week, so total testing time will be about 9 weeks.

Of course, this assumes complete code coverage and a constant rate of testing.

Hope this is clear.

Mike J. Berry
www.RedRockResearch.com

Mike J. Berry
www.RedRockResearch.com
Software Developement Process Guidance

Mike J. Berry
www.RedRockResearch.com

Here’s an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  OnLine Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system’s business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the ‘rollback point,’ which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to ’check’ completed checklist items and sign-off sections they are responsible for. 

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.   

If you like, add a ‘lessons learned’ section to be completed later, and keep a copy of the execution plan for historical purposes. 

Mike J. Berry
www.RedRockResearch.com

‘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

I classify a ‘repeat visitor’ as somebody who has come back four or more times.   The number four is kind of arbitrary, but I think somebody who comes back only once or twice is not really a captive audience participant.  They are more link a potential customer peering into the store window.

NewsCHIME.com was created to bring headline news to people who, like me, love to read the news.   We love it so much, in fact, that that’s all we want to see on the site–news headlines and nothing else. 

Have a BlackBerry and a few spare minutes between (or during) your meetings?  Go to NewsCHIME.com and check out what’s happing across the world!

Need to do research for education, work, or personal interest?  You can search for headlines topics from the past 18 months or so on the search page.  

This works great if you are expected to know about something newsworthy in a short amount of time.

For example, a search for ‘Obama’ or ‘McCain’ and a quick headline perusal will give you a one-sentence summary of everything noteworthy these candidates have done for the past 18 months.  10 minutes on NewsCHIME and you be more infomed about the upcoming presidential election than more than 300 million other people.

Need research project material on the mortgage meltdown, type ‘mortgage’ and you’ll see the unfortunate play-by-play.

Be sure to take note of what you will NOT see at NewsCHIME.com.  You will not see lots of useless links to various websites that have nothing to do with your topic.  You will not see pictures of dancing people,  and you will not see ads from GM, Chevy or eHarmony. 

I almost forgot to mention, NewsCHIME has free news alerts!  That’s right, Free!  Sign up and select which search criteria you want, and as those terms are named in news events you’ll be the first one to know about them. 

So, impress your friends, impress your boss, impress you teacher.  The faster you can get at information, the more beneficial your decisions will become.  Enjoy.

Mike J. Berry
www.RedRockResearch.com

I’ve seen employees motivated for many different reasons: recognition, financial incentive, empowerment, personal growth, tension release, fear, and finally there’s that weird Lord of the Flies thing where employees get motivated together against another employee. 

In their book, Motivating Employees, Anne Bruce and James S. Pepitone describe the most effective ways to motivate a team.  They describe the three C’s which are vital to functionally motivating employees:

1. Collaboration: Be sure to involve employees in decisions and discussions where their efforts are involved.

2. Content: As they produce suggestions, act on those suggestions immediately.

3. Choice: Be sure to offer choices to your employees–even if you can predict what they will decide. 

These three techniques actually empower your employees.   Involving employees in decisions that affect them, or the outcome of what they are working on produces a level of buy-in that is hard to match any other way.

Bruce and Pepitone continue with an examination of Theory-X and Theory-Y motivation and management styles.  These styles were originally presented in the 1960’s by Douglas McGregor. 

McGregor states that Theory-X managers proceed from the assumption that their employees are uninformed, lazy, and needy of high-structure. 

Theory-Y managers, however, proceed from the assumption that their employees are qualified, intelligent, and capable of making proper decisions provided they are given proper goals, accountability, authority, and resources to accomplish their tasks.

Although Theory-X is the most effective approach during some situations, if you consider the amount of college-educated employees in the workforce today, it’s easy to see how Theory-Y, if applied properly, yields much higher performance.

The authors continue with a formula for encouraging Entrepreneurial Thinking.   Their five-step formula is:

1. Explain the organization
2. Demonstrate how the organization operates and generates income
3. Help your employees understand the competition
4. Encourage intelligent risk-taking
5. Inspire innovative thinking

Another great idea the authors present is to link motivation to performance.  They suggest you develop a written-list of performance standards for meeting and exceeding the expectations you’ve agreed upon during collaborative sessions with them.

The authors talk about how important it is to weave fun into everything your organization does.   This may sound like a unusual suggestion at first, but the authors point out that there is a direct correlation between fun on the job and employee productivity, moral, creativity, satisfaction, and most importantly–retention.

The final few chapters in the book discuss de-motivating factors (or individuals), and how to deal with them.  There is also a good chapter on conducting effective employee-reviews.

Overall I recommend this book to any manager.   It’s a great book to re-read every so often.

Mike J. Berry
www.RedRockResearch.com

Here’s a fun site if you are a news junkie.  www.NewsChime.com is a simple site that grabs news headlines from major news sites and lists them in an easy-to-peruse text-only format. 

I’ve got the site on my PDA which makes reading news articles perfect for that boring meeting or that inconvenient 10-minute wait you hadn’t planned on.

An interesting feature on www.NewsChime.com is the ability to search for keywords in past news headlines.  Want to know what has been newsworthy about Hillary Clinton, or Barack Obama?  Housing Crisis?  Gas Prices?  You can easily search for past headline keywords with this feature.

www.NewsChime.com also allows you to get news alerts sent to your phone or email.  I have news alerts sent to my phone about mortgage prices, home-loans, home-lending, and foreclosure because we talk a lot about this at work.  It’s been fun to be the first one at the office to know the latest.

www.NewsChime.com is a free service.  Enjoy.

Mike J. Berry
www.RedRockResearch.com

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

Over the years I have thought often about the answer to this question.

My earlier conclusion was that professionalism meant a separation of work and personal life.  This is something that I think the older generation is better at.  The younger generation seems more transparent about personal matters in the workplace. 

As the years go by, however, my experience doesn’t support this conclusion as a definition of professionalism.  I find many professionals are actually quite personable.

This has caused me to re-evaluate the answer to this question.

I think the answer I would give now is that professionalism means ownership.  It means responsibility and accountability for producing the appropriate results.

I walked into a CostCo last week looking for a large household item.  I found a smiling attentive employee with whom I asked where I might find the item I was looking for.  He said “I’m new here,” and shrugged his shoulders.

There was this moment of pregnant miscommunication.

No doubt he was unable to help me due to his present unfamiliarity with the store layout, but as a customer I felt neglected.

I thought to myself, “Well, are you going to get someone for me who knows where this item is?” And then I realized I had, perhaps, misaligned expectations for customer service from a new employee at a wholesale warehouse selling everything from car tires to margarine.

Then the light bulb went on—a more professional employee would have “owned” my problem.  They would have found someone who did know where my item was and would have walked with me until my problem was solved. 

Suddenly I realized I had the answer to my decades-old question: Professionalism means ownership.   Ownership of issues.  Ownership of assignments.  Ownership of tasks.

My thanks go out to the anonymous clueless employee.  After several decades, I finally have my answer.

How would you answer this question?

Mike J. Berry
www.RedRockResearch.com
 

Companies that don’t have a quality system are commonly reacting to production and support issues due to omissive events.

A simple rule of thumb is to ask yourself how many fires your development team has put out this month.  If any come to mind, then chances are you don’t have a proper quality management system in place, and should read on…

I remember early in my career I struggled to get my employees to follow our procedures.  Whenever we’d encounter a production problem with our software, it would inevitably be a result of someone not having completely followed an established procedure. 

We would have a big discussion about what should have happened, and about how “we can’t forget to do that next time,” yet we’d experience the same omission later.

I would get frustrated because I could never seem to find a way to get my team accountable for following our established procedures–until I discovered the “Quality Management System.” 

A Quality Management System has the following three elements (the Three P’s!):

1. Process (documented–most of us have processes or procedures we are supposed to follow.)
2. Proof (a separate checklist, or “receipt” that the process was followed for each software release.)
3. Process-Improvement (a discussion, and then an addition or adjustment to the documented process.)

Most companies have an established–and hopefully documented–software development process.  (If you don’t you can download one from my website for Waterfall, or Agile here.)  This is the first ‘P’ and should be in place at every established development shop.

A great question to ask the team is “How do you know the process was followed for each release?”  This is where you may get the deer in the headlights response.  This is the second ‘P’ and is the piece missing from most software development shops.   

Think of this ’Proof’ document as a checklist accompanying each software release.  The checklist would include every major step in the documented process, names of team members performing specific functions, and locations of final source code, test scripts, install files, etc.  The checklist would also require a series of quality checks.  Ie: Were requirements signed off by the customer, stakeholder, tester, and developer?  Was the help file updated with the new release number and appropriate functionality?  Was the source code checked in?  Where is it located? 

As problems occur, the checklist would be added to so that the product would be protected against a similar failure in the future. 

The governing driver considered here is that one particular problem might broadside the development team once, but after the process is improved, that problem should never occur again.

For example, you might have a stored procedure that goes into production without a “Go” statement at the end.  After the error is discovered, and fixed in production, your team should have a discussion and conclude that a checkbox needs to be added to the quality document stating “All Stored Procedures Confirmed to have ‘Go’ at the end.”

From that point on, whenever a stored procedure is moved into production, the developer presenting it must check for ‘Go’ statements at the end and then sign their name at the bottom of the checklist.

This is the difference between process improvement, and hope.  Many companies view process improvement as a discussion and some verbal affirmations.  What they are really doing is “hoping.”

Actually, the “act” of process improvement is physically altering a written process or procedure.  This is the real definition of process improvement–the third ‘P.’

The final endpoint of a quality management system is to achieve excellence.  I’ve heard excellence defined once as “Crisp execution of established procedures.”

You can’t have excellence without procedures, proof, and process-improvement.

Mike J. Berry
www.RedRockResearch.com

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 effecient?  What suggestions do you have about how to convey project status communication within your organization?

Mike J. Berry
www.RedRockResearch.com

 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

Depending on your particular situation, you’ll likely have to meet many new people, learn about new systems, and remember to smile often.

A good starting point is the be sure the following items are in place:

1. Make a contact list of everyone in your department, your peers, you manager.  Include their desk phones, mobile phones, and email addresses.  Keep this list updated.  You will use it for a long time.
2. Find or Create the ‘Development Procedures Manual.’  Include in it the following:
   1. Corporate Mission/Vision Statement & Values
   2. Department Mission/Vision Statement & Values 
   3. New Employee Hire checklist
   4. Development Workstation Setup checklist
   5. Software Development Procedures
   6. Coding Standards
   7. VPN Setup Instructions
   8. Weekly Meeting Schedules
3. Create a ‘Development Managers Log’ containing the following:
   1. Employee Time Off Log
   2. Observed holiday list
   3. 3rd Party Software Licensing information
   4. Historical Release Log
4. Be sure you have a source code repository
5. Be sure you have an issue tracking system  
6. Review/Create the Disaster Recovery plan for all of your critical systems:
   1. Source Code Repository
   2. 3rd Party Code libraries
   3. Issue Tracking System & DB
7. Make a ‘projects list’ containing an ever-updating list of projects and their status.
8. Have a ‘welcome meeting’ with the group you oversee to tell them something about you.  Whomever interviewed you knows about you, but chances are the group you are now managing doesn’t.  Tell them your past work history, your management style, communication plan, and something fun and personable about yourself.
9. Ask your group what would make their jobs more rewarding.  Ask this question a lot at first because they won’t believe you mean it until you have asked the question many times. 

 Good Luck!  You’re off to a good start!

Mike J. Berry
www.RedRockResearch.com

I told her that hiring is always a bit of a dice roll, but I offered her some advice after having hired about 15 people at various times in my career:

1. The most important indicator of future success is past success.  Good interviewers know this.  Dig into people’s past work experience and try to find out if they have been generally successful, or not.  Some indicators of this are whether they have changed jobs often.  If they jumped jobs on their way up the ladder of responsibility, this is OK.  If they jumped sideways, or sometimes down, this is a red flag.  Drill them about each job change.  You will get interesting results.  People will say they were fired, or had fights with their boss or coworkers.  These are usually not your desirable candidates.  If they fought with their previous peers and managers, chances are they will fight with your group also.
 
2. Look for enthusiasm.  Enthusiasm is a great sign of a star employee.
 
3. Examine their personal lives (you really can’t do this in an interview).  But whatever they tell you can be a clue as to how they respond to accountability, pressure, authority, and responsibility.  If they hate police, or the government, or have been divorced five times, then they may have issues with authority or responsibility.  You have to be careful here because you cannot descriminate.
 
4. Call their references and ask their references if that person was successful, and if they would re-hire that person.  Ask how socially distracting they were inside the workplace, and what time they came in the morning and what time they went home.  Ask if they were a good team-member, and if they were typically dependable enough to get things done.  Ask why they left and compare their answers to the candidate’s explanation.
 
5. Because software development is not always a 9-to-5 job, a good question to ask is if they have any extra-curricular activity that would prohibit them from staying late if needed.  I have hired people to discover that every day at 5:30 they need to pick up their kid from daycare.  This obligation makes them incompatible with leading a team that may require them to stay late and fix a critical problem.  This is a good thing to find out before you hire someone for a position like that.
 
6. Try to get them to express an opinion about something business related and that they are passionate about.  Pay attention to how they express their opinion.  Do they express themselves dogmatically, as if their opinion is fact and you must argue with them to object, or do they express their opinion in a collaborative way, where they would be more of an asset in a group discussion where others may disagree.

7. Pay attention to how they show up for the interview.  Are they on time, and dressed for the part.  Did they bring with them a copy of their resume? Are their shoes shiny?

8. Ask them several obvious question about your company to see if they did any research before the interview.  Find something on your website homepage that they would know if they looked there before the interview. This is a clue as to their proactive abilities. 

9. Pay attention to how they describe their previous workplace, management, and executive staff.  This will likely be an indicator of what they will think of your staff.

10. If you sense an extreme level of dissatisfaction, high-maintenance, or lots of questions about what’s in it for them—beware!  This is an employee that will likely perform the bare minimum and be unnecessarily needy.

There are lots of books and tips about how to be the interviewee, but not so much is written about how to interview.  I wish I could have read these tips years ago when I began hiring people.  I hope this helps others and I would be interested in hearing what readers have to add.

Mike J. Berry
www.RedRockResearch.com

Goldsmith is an executive coach who has worked with more than 80 of the worlds foremost CEO’s.  As a symbol of his influence,  Alliant International University recently renamed their school of management after him.  With these credentials, probably anything he writes is worth reading.

In his book, Goldsmith lists twenty-one common “soft-skill” dysfunctions he has encountered while coaching top executives.   He explains that the higher you go in executive management, the more your problems are behavioral.  A few of these behavioral problems are as follows:

1. The need to win to much
2. Making destructive comments
3. Starting sentences with “No,” “But,” or “However”
4. Telling the world how smart you are
5. Speaking when angry
6. Withholding information
7. Clinging to the past
8. Playing favorites among direct-reports
9. An excessive need to be “Me” (or, “I can’t change, that’s just how I am”)
10. Goal obsession

To get the whole list, you need to read his book.  The first half of the book details these ten and the other eleven common issues at length. 

One of the primary challenges Goldsmith writes about is getting executives to understand how they are perceived by others in their work environments, and at home.  He separates our personal “perception” into four categories: 

1. Public Knowledge (Traits known to others and self)
2. Private Knowledge (Traits known to self but not to others)
3. Blind Spots (Traits known to others but not to self)
4. Unknowable (Traits unknown to others, and not know to self)

Goldsmith says that the most interesting traits to examine and study are #3, the blind spots known to others but not to ourselves.  He provides a formula for detecting these traits, examining them, and fixing any negative discoveries.  The formula is:

1. Collect feedback from everyone around us, using both deliberate and subtle tactics.
2. Apologize to everyone for any negative traits.
3. Advertise that you are beginning a personal campaign to improve and that you would like their feedback periodically as you work on improvement.
4. Listen to feedback in terms of “what can I do in the future to improve” and not “what did I do wrong in the past” (one is positive, one is negative)
5. Thank people for their suggestions, and don’t disagree with them.
6. Follow-up relentlessly.  This is the key to the improvement process taking shape.

He explains, for example,  that as a professional coach, he and a colleague call each other each evening and report to eachother on the progress of their goals.  This simple practice enables them to metric their performance over time–the same thing effective executives do to examine trends in their departmental interests.

Goldsmith discusses several other topics in his book.  One interesting aside is a list of common reasons why goal setting can fail:

1. Time: It takes longer than expected, so it couldn’t be completed.
2. Effort: It’s harder than was expected.
3. Distractions: Nobody expected a “crisis” to emerge that took resources or time away.
4. Lack of Rewards: After they see some improvement, they don’t get enough positive response from others, so they give up.
5. Maintenance: Once a goal is met, there is no fortitude to stick with the pattern that brought success.

One of the closing thoughts in Goldsmith’s book struck me as quite novel.  As one of his executive coaching tools, he sometimes asks executives to produce a “How to Handle Me” guide for his staff.  This is a short memo detailing behavior, values, lessons from past experience, and input from past and present coworkers and direct reports.

As new hires are onboarded, part of their welcome packet is the “How to Handle Me” guide from their manager.

I found the most valuable part of Goldsmith’s book to be his formula for collecting feedback about others’ perceptions of us, and how we can affect change within ourselves where needed.  I appreciated Goldsmiths continuous transcentions that all of these tools and dynamics also have value at home to improve our family lives and social relationships.  This was a reoccurring theme in his book.

I recommend Goldsmith’s book for middle to senior level management, and to any husband or wife.

Mike J. Berry
www.RedRockResearch.com

Maxwell starts his book by dispelling many common dysfunctional myths that are found at line-level, or middle-level management.  Ideas such as “When I get to the top, I’ll be in control,” and “If I were on top, then people would follow me” are inaccurate adolescent attempts to understand the true nature of leadership–which is influence.

Maxwell continues by explaining the characteristics of influence:

1. Position - Influence because people have to follow you.
2. Permission - Influence because people want to follow you.
3. Production - Influence because of what you have done for the organization.
4. People Development -Influence because of what you have done for them.
5. Personhood - Influence because of who you are and what you represent.

Maxwell gives examples of effective leadership in all directions: up, across and down.

To lead up well, he suggests you lighten your leaders load, anticipate your leaders needs and use their time wisely, and invest in Relational Chemistry–get to know what makes your leaders tick.

To lead across, Maxwell suggests you focus on completing your fellow leaders, instead of competing with them.   Be a friend, don’t pretend you’re perfect, and avoid office politics.

To lead down, Maxwell suggest you develop each team member, place people in their strength zones, model the behavior you desire, transfer the vision from above, and reward the results you desire.

Overall this is a good book worth reading and re-reading every so often.  I recommend it for managers at all levels.

Mike J. Berry
www.RedRockResearch.com

As of late, corporations have discovered that mission-statements are only somewhat helpful in providing direction to a company.  Being strategic in nature, they don’t provide enough detail to govern tactical decisions made by the corporate employees on a daily basis.

To answer this need, value-statements, and value-systems have come into vogue.  Many companies have value-statements to underscore their mission statements. 

Just as some mission statements are more effective than others, some value-systems are more effective than others.

The simple approach to establishing corporate, department, or team values is to get everyone together in a room and have them suggest values the team should adopt.  Voting happens, and the group committs to their agree-upon values.

After one of these sessions, the group might come up with a list like:

• respect
• trust
• excellance
• high performance

This list is a start, but only representative of a one-dimentional value system.  These values, by themselves, realy don’t project any context or weight.

A more effective approach would be a two-dimensional value system.  A two dimensional value-system provides a greater context fabric.  For example, you could say your group values:

• respect over cynicism
• trust over hope
• excellence over heroics
• high-performance over sub-optimization

These comparison value statements proved direction and context.  This represents a two-dimensional value system, and is more effective that a simple list of values.

A three-dimensional value system is a prioritized list of these comparison statements.  For example, you could say your group values these statements in this order:

1. trust over hope 
2. excellence over heroics
3. high-performance over sub-optimization
4. respect over cynicism

This list shows that trust is the highest factor in inter-departmental dynamics.  It shows that excellence is more important than high-performance (so no cutting corners!), and that the group values trust, excellence, and high-performance more than respect. 

Every group will have their own values and differences in priorioties, but putting a three-dimensional value-system in place with your team is a great step forward in building functional team cohesion. 

Once in place, a reward-systems can be built around your value system to promote it’s effectivness.

Mike J Berry
www.RedRockResearch.com

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

My friend and associate, Greg Wright, told me about an interesting process for improving morale that his company practices. 

They have an appeasement committee and budget.   The appeasement committee is a group with one representative from each department.  Each month, a different member of each department is represented in the group.  If certain corporate goals are met, the committee plans an event for the company for that month.  The events are simple and not too expensive:  bowling, or mini-golf and pizza, etc. 

What I find valuable about this example is that five important objectives are met:

1. The individual employees are empowered by being able to participate in the suggestions to improve morale.  This personal involvement is more meaningful to them, and more appreciated.
2. If a committee and a budget is in place, morale-building events won’t take a backseat to unexpected fires, or brand new deadlines.
3. The effort-vs-reward principal is set in motion, which is one of the foundations of capitalism.
4. Corporate goals get communicated, and emphasized, and are constantly on everyone’s minds.
5. Team-building outside of the stressed work environment will occur.  This brings a fresh dimension to work-place teamwork.

Morale building is important because it separates the sweat-shop jobs from the career jobs.  This simple process can do wonders for your organization.

Mike J Berry
www.RedRockResearch.com

Ferriss’s book is about beating Corporate America, and becoming content and happy using the newer technologies available to us today. 

He provides a formula for successful entrepreneurship.  One important point he makes is the need to find a market, before investing in building the product.  He suggests this successful pattern:

1. Pick an industry you understand.
2. Target a product you can Create, License, or Resell.
3. Look at competition to see how you need to differentiate your product.  Examples:
   1. More credibility indicators
   2. Offer a better guarantee
   3. Offer a better selection
   4. Offer free, or faster shipping
4. Micro-test your product (before you put any money into it), by using eBay, or Google Ad’s.  Microtesting is “probing” customers to see if they would buy the product.  Some examples:
   1. Put an add on eBay, then cancel the add minutes before the auction ends, to see how much people are willing to pay.
   2. Build a dummy website, with item, description, pictures, and pricing.  After the user pressed ‘purchase now,’ display a “Thank you but this item is temporarily unavailable.”  This enables you to test your conversion rate up front, without needing to invest in manufacturing, etc.

This way, you can determine up front if there is a market for your product.  He suggests putting the price on a separate webpage altogether so you can measure the effects that changing the price alone will have on your conversion rate.

Ferris goes on to explain how to transform managing a business into automating the business.  He suggests time management is a thing of the past.  The key to living better today is to remove distracting inputs from our lives. 

He talks about outsourcing every part of you business and empowering the outsourcers.  He talks about only answering email one day a week, and having your cell phone message redirect people to you email. 

The final part of Ferriss’s book talks about what to do after you have successfully started and automated you business.  He talks about getting out of your comfort zone, travelling, learning new skills, and new languages. 

I think this book is an excellent read, and surprisingly cutting-edge.  It’s nice to read a business book about PPC, Google AdWords, and eBay microtesting.   Makes me feel understood.

Mike J Berry
www.RedRockResearch.com

Halo 3 is the third installment in Bungie’s highly-popular XBox video-game series.  The storyline takes place in a futuristic world that has been infested with an alien army.  Led by a creepy villain who calls himself the ‘Prophet of Truth,’ the alien onslaught will annihaliate the entire human race unless, of course, you and the space marines expel them. 

Halo 3 is a little twist from 1 and 2 because you have an alien-defector who helps you during most of the levels, and well, it’s the Xbox 360 this time! 

The graphics are outstanding and the playability is great.   I remember playing Halo 1 with my friend, Greg Wright.   He came to my house the day I brought the game home.   It was around 5pm when we started playing the game.  After what seemed to us to be about three hours, his wife called us to ask if her husband was ever coming home again because it was 2:30 am and she hadn’t heard from him.

With Halo 2, my neighbor Rob and I finished the campaign game in about two weeks.   We’d play every night until about 1 am.  By then, our brains were so fried we couldn’t speak properly.  We had to use hand signals to communicate ‘good-night’ and ’same time tomorrow.’

My all-time favorite games were Bolo and Bilestoad on the Apple II, Doom and Klingon Academy on the PC, and 007 on the N64.  Ghost Recon is my most-played XBox game, and so far, Halo 3 is the best 360 game.

Heroic is a difficult level.  It took me about three months to complete, playing solo and moderately during that time.  The first few levels are pretty easy.  You basically shoot anything moving at you.  As the game progresses however, you start facing more difficult aliens and tougher challenges.  

Here are some strategies that helped me:

1. Learn to be patient and lure the bigger aliens out one-by-one.  You have a much better chance of being successful facing them one-by-one.

2. Don’t feel compelled to annihilate every alien you come across.  Sometimes, the melee was so chaotic it was simply easier to run past everything and through the next door.

3. Discover your melee-punch attack.  This is where you run up on an alien, and punch them with your weapon.  I found this to be the best way to clobber a tough alien.  One or two hits and you can take down a Brute.  This works especially well inside a shield-dome.

4. Chieftains are the toughest opponents.  Wielding gravity hammers, and invincibility armor, they strike pure terror when they run at you.  There are three excellent techniques to use to defeat them:

A. Blast them with plasma cannons.  The continuous impact will stun and drain them of health.

B. If you have an invisibility shield, go invisible, quickly walk up behind the chieftain, and melee punch him in the back several times. 

C. Learn to jump up over them when they run at you.  You can stay alive and shoot at them for a while doing this.

5. Attack the exhaust vent of the Wraith.

6. Attack the legs of the Scarab SuperTank, then jump on, run up to the top, and blast it’s power source.

7. This should be obvious to you– running over the aliens is easier than shooting them.

Halo 3 is a guys game.   It’s full of marines, monsters, lasers, rockets, jeeps, four-wheelers, space-ships and shooting.  There are only three women in the game.  A dispatcher who you never see,  the operations commander, and an attractive computer persona.

There are nine levels.  The environments range from jungle, to desert, to internal facilities, to inside creepy, fleshy-spaceships.  The final level is a unique racetrack-like experience.

I really liked the humor in the game.  The little grunt aliens see you coming and say “Oh, no!  A monster!”  Sometimes the little grunts poke fun at their bigger alien buddies by saying “Brute’s are jerks.” 

The brutes have their own humor.  They are big, scary aliens that speak with deep voices.  Sometimes, when you die, one of them will say ”All to easy…” which is a direct quote from Darth Vader. 

The brute comment that makes me laugh the most is sometimes heard when you are unfortunate enough to come across a mass of Brute aliens marching towards you.  One of them will say, in their deep, Vader-like voice, “No inappropriate touching!”

I noticed a recent news snippet that Microsoft has released it’s seven-year hold on Bungie.  They’re now free again to wow us with more great games.

I really enjoyed playing this game.  I guess I’m ready for some Halo parties, now.  If you are having one, let me know.  Find me as MBER on Xbox Live.  I’d welcome some comments from others who have finished the game.

Mike J Berry
www.RedRockResearch.com

In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do.  It’s refreshing to read a software development book that tells you ”what to do” for a change.

Sullivan skips past conventional theory and provides real-world experiences and wisdom for how project managers and software development teams can succeed in this challenging industry.

Novel to Sullivan’s recommended approaches is the concept of one-team-per-project, reporting to a single manager.  Conventionally, most companies split out development, quality-assurance, and product management into different departments.  Sullivan describres this configuration as a model set-up-for-failure.  Too many factors, he says, complicate team performance when each team-member is reporting to a separate manager.

I consult with software development companies to improve their product delivery speed and product quality.  I call Sullivan’s single-team suggestion the “lean model,” and I agree with his conclusions.

In the manufacturing sciences, there is a belief that the production manager and the quality assurance manager have an inherent conflict of interest, therefore, they should be separate departments within a manufacturing organization.  Many business books are written about this.

In software, however, this model is a less-effective approach.  It can work, but it creates barriers between project teams for several reasons:

1. Contention can arise as an “us vs them” mentality builds when team-members go back to their respective departments dougouts, to commesurate with their non-project department staff.
2. As team-members need each other to succeed, it becomes easy for a team-member in one department to delay requests, or grandstand, because their department manager “has asked them to work on other things this week.”
3. A department manager will tend to be uninformed about upcoming urgent project team needs and may unintentionally delay the project by asking their employee to do other things at the most inconvenient time for the project.
4. A lack of focus will accompany any project team-member who has continuous department responsibilities outside of the project team.
5. If contention arises, the project team-members from different departments may value disparaging another department, rather than working together to solve the problem at hand.

Sullivan goes on to discuss effective hiring techniques, retention techniques, and general healthy corporate culture factors.  He talks about ranking employees in terms of inner-circle, middle-circle, and outer-circle.  This reminds me of Jack Welch’s theory on differentation.

Another novel concept Sullivan describes is his simple but effective project scheduling process.  He breaks each month into daily rows, listing team members names as column headers.  Inside of each cell is a letter/number combination representing who needs to be finished with what task on that day.  In my opinion this is much better than a gantt chart.

Sullivan goes on to describe meetings, schedule management, release management, and project closure.

I found this to be a beneficial book to read.  I would recommend reading it topically, as a reference, rather than cover-to-cover.

Mike J Berry
www.RedRockResearch.com

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

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

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

Maxwell breaks down leadership into 21 categories.  He then goes to great lengths to explain each category and give real world examples. 

He describes the progression of leadership by highlighting great leaders who have created momentum in others around them.  For example, he explains that early in Michael Jordan’s basketball career, he relied heavily on his personal talent to win games.  But as he matured, he turned his attention more to being a leader and making the whole team play better. 

Jordan is quoted in the book as saying, “That’s what everybody looks at when I miss a game.  Can they win without me? …Why doesn’t anybody ask why or what it is I contribute that makes a difference?  I bet nobody would ever say they miss my leadership or my ability to make my teammates better.”  Yet, that’s what made him such a great teammate.

Some of Maxwell’s principles are predictable and conventional, but some of them are quite novel.  I enjoyed reading about the Law of Magnetism and the Law of Connection.

The Law of Magnetism states that you are who you attract, and the Law of Connection states that you must touch people’s hearts before they will trust you.

This book is a great reference for leaders in all stages of their career.  A New York Times, Wall Street Journal, and Business Week bestseller, I highly recommend you buy it, read it, and consult it often.

Mike J Berry
www.RedRockResearch.com

Sutton makes a case for the need for insight and direction in handling Bullies, Creeps, Jerks, Tyrants, Tormentors, Despots, Backstabbers, Egomaniacs, and any other kind of workplace employees who never learned to play Sandbox 101.

I found the book to be an inspiring read and found that it was full of great advice.  Two interesting management take-aways I got from reading the book were:

1. Corporations loose money due to unbridled “jerkism” and the author suggests that the cost should be tracked in terms of a “TCA” (Total Cost of jerks) metric.
2. Due to #1, progressive companies need to have instilled in their corporate values, policies, and hiring processes, the sentiment that being a jerk is incompatible with the corporate culture.   Interestingly enough, companies like Google actually have anti-jerk clauses in their employee handbook.

If you find yourself working with a jerk, you can do the following:

1. Minimize your time spent with the jerk.  Don’t pick projects they are on, don’t attend optional meetings they are in.
2. Another tactic is to lesson the influence the jerk has on your department and in the company in general.  Try to steer new obligations and assignments that effect you away from that individual.

I found Robert I. Sutton’s book to be an interesting read.  Sorry about the title, Mom.

Mike J Berry
www.RedRockResearch.com

I have to admit this book seemed much like many of the other “improving business performance” books that I have read, except that this book kept me confused through most of it.

The authors discuss seven different types of organizational profiles, some functional, and some dysfunctional.  After reading the book, I’m still not quite sure which was supposed to be which.  I even found the diagrams in the book to be confusing.

Here and there, the authors have little nuggets of good advice.  For example, they remind the reader that strategy doesn’t bring results, execution does.  And, that execution won’t happen successfully until the right people have the right information and the right incentives.

Despite the confusing text, I can tell the book had a lot of research behind it.  I wish the authors would have simply summarized all of their findings and presented the material with a “how to” model.

Unfortunately, I would not recommend spending time reading this book.  I think for the time invested reading all 279 pages, there are other books in this space that will offer more valuable take-aways.

Mike J Berry
www.RedRockResearch.com

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

Although it has been titled for “The First Time Manager,” there are enough gold nuggets in this book for seasoned managers as well.  Now, in it’s 5th edition, you can be assured it has been refined and reality-tested. 

Belker and Topchick present guidance to many areas that managers need to navigate when managing people.  From building trust, to building team spirit, to managing problem employees, to hiring and firing, and so on.

They point out that managing is not about directing people, it is about getting people to become self-directed.  They talk about personal style and communication, dealing with stress, and finally having an effective work-life balance, and a touch of class.

I would recommend this book to any manager.  It makes a great reference to consult from time to time.

Mike J Berry
www.RedRockResearch.com

Following Jack Welch’s direct, no-holds-barred style, he presents quite plainly the road-map to successful management.

He talks about constructing corporate values and effective mission statements.  He talks about the importance of candor, respect, and effective reward-systems.  He continues with topics on Crisis Management, Change, Strategy, Budgeting, People Management, and finally Work-Life Balance.

This book is full of take-aways and insight.  It’s a real wonder to be able to take decades of Jack Welch’s experiences and have them condensed into a single book.  If you haven’t read this book, you should.  Soon.

Mike J Berry
www.RedRockResearch.com

This is an interesting book that speaks to the great “divide” in corporate America.  The divide, they say, is the distinction between how management conducts themselves in relation to their teams they manage.

The authors suggest corporations function better with a “flat model.”  Their suggestions are:

1. Leaders should never command or dictate change.
2. Employees should always be involved from the very beginning.
3. Executives should not get privileged parking spaces.

Well, OK, the third point was not emphasized heavily, but was mentioned.

The flat-management approach emphasized in this book relates well to Agile Development team dynamics.  In an effective Agile team, input and influence from all are needed to produce superior customer value in the software product.  In fact, this book is listed as a favorite read on the ScrumAlliance.org leadership reading list.

 The most valuable takeaway I got from reading this book was to think in terms of how my actions, as a manager, can either emphasize or minimize the space between management and the team.  A great suggestion they gave was to hold a team meeting directly after the executive meetings, thus symbolically minimizing this divide.

I think this is a good book to read once.

Mike J Berry
www.RedRockResearch.com

This New York Times bestseller is an analytical exploration into social cause and affect.  Using analytics, Levitt shows how he was able to detect administrative cheating in the Chicago school districts, prove that sumo-wrestling is fixed, and suggested which baby names will be most popular in 2015.

I can’t say enough good about this book.  It was compelling to read, and a great mind-opener about the value of the relatively-new field of business analytics.

Mike J Berry
www.RedRockResearch.com

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

,

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

Secrets of Great Rainmakers: The Keys to Success and Wealth 

Fox’s book is rare in that he has interviewed many “rainmakers” and taken their personal philosophies and stories and complied them into this book.   He discusses many topics including “Heed the first Buy Signal” and “Killer Sales Questions #1 and #2.”

Most touching to me was his chapter on Paperboys.  It seems the majority of the rainmakers and highly successful people he interviewed had in common a first job as a paperboy.  He said, if you have to hire two equal candidates, but one had a paper-route in their youth, and the other did not–hire the paperboy.  This made me feel good because I come from a family of paperboys.

Mike J Berry
www.RedRockResearch.com

How to Talk to Anyone, Anytime, Anywhere: The Secrets of Good Communication

Larry did a service to the public by writing this book and elaborating on some guiding principles that have helped him succeed in his career of–well, talking.

Novel among his concepts is the premise that successful people are good talkers and good talkers are successful people.  I can’t think of a more appropriate industry than IT to be reminded that we need to improve our speaking skills.

Larry’s stories transcend many areas of life: from managing people, to interviewing for a job, to public speaking, to talking your way out of the principal’s office–Larry has a story for everyone in this book.

Mike J Berry
www.RedRockResearch.com

In Integrating Agile Development in the Real World, Peter Schuh explains in depth how to get your team to adopt the Agile Development Model.

Schuh covers several Agile Metholodogies including the problems to watch out for during the process.

I do have to say, this book seemed like a “whole bunch of everything” and so I didn’t feel, after reading it, that I was really any more informed about Agile Development.

I would recommend the book for a group just being introduced to the Agile Development Model.

Mike J Berry
www.RedRockResearch.com

Optimizing Corporate Portfolio Management: Aligning Investment Proposals with Organizational Strategy

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

The Five Dysfunctions of a Team: A Leadership Fable

Lencioni’s style with his books seem to be a sort of fable-story-type narrative in the first part, and then real meat in the latter part.  I have to confess I skipped about half of the fable stuff, but found the meat at the back to be very interesting.

The five dysfunctions he examines are:

1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results

Being a single guy, I could most readily identify with #3, Lack of Commitment.  And the more I think about it, all of these dysfunctions could be more-or-lesss applied to dating.

His book comes complete with a team-assessment worksheet, and directions on how to identify and overcome these five dysfunctions.  A good read for any manager.

Mike J Berry
www.RedRockResearch.com

The Tipping Point: How Little Things Can Make a Big Difference

Gladwell points out the two phenomenons that seem to primarily be market catalyst factors:

1. One high-profile, highly-connected individual’s public endorsement
2. A critical-mass buildup of interest

Gladwell suggests people like Oprah Winfrey can have great power in markets, and sites her single negative market-shaking comment about the U.S. beef industry back in the 80’s as an example of such dynamics.

I found the Tipping Point to be an inspiring read and highly recommend it, especially to the marketing types.

Mike J Berry
www.RedRockResearch.com

Blink: The Power of Thinking Without Thinking

Gladwell talks about several interesting documented situations where seemingly factual information purported to suggest one reality, but an intervening expert just “knew” something wasn’t right and–with further research–was able to bring the real facts to light.

I enjoyed reading this book and it reminded me of all of the amazing women around me that seem have this gift, inherently.  Now that I think about it,  Gladwell was probably writing this book just for men.

Mike J Berry
www.RedRockResearch.com

We discussed various successes and challenges with using the Agile Development Model for software development.  One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids.

Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work.  They gave us some insight on how to proceed.

The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions.  They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates.  All of this is measurable, so it works very well with the government procurement types.

Agile is a less structured methodology–where you build requirements and code more in a module, by module format.  These modules, called user-stories, aren’t spec’d in detail until they are actually being worked on.  Because of this, milestones and time-lines for an Agile project are not as predictable.  The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.

The trick with the Government is to bid your first project as a waterfall project.  Then, after you have a relationship, suggest that forthcoming projects have an Agile model.

You can also submit a Waterfall project with some additional requirements listed on the contract.  ie: “Requirements base-lined at a high-level” or “Progress reported via Project Backlog” or “Prioritization by Need” or “Daily Scrum” or all of these things.  

Mike J Berry
www.RedRockResearch.com

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

…but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives?

Don’t get me wrong.  I’ve grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name. 

Because SQL Server (and Oracle) are highly visible in the public’s radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier.

So my client is spending $500,000 and seven or eight months upgrading their core product–and all of the internal support tools that must work with it–to SQL 2005.  Again why?  To ‘add value to the customer experience’…meaning that the salesperson can say “yes, it works with SQL 2005.”

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for ‘clues’ of what should separate an inferior product from a superior product, and–well–version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer’s radar.  This way, they would have no ‘journal information’ about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft.

PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn’t affect you, but if you make a commercial client-server product, there’s no doubt you’ve experienced this already.

Mike J Berry
www.RedRockResearch.com

One of the more innovative approaches to cutting down on meeting drain is the concept of the ’stand up meeting.’  This is were all participants (except maybe senior citizens) stand for the duration of the meeting.  Amazingly, during this process, nobody seems to have long weekend stories to tell the group, and answers and discussion points become more concise.

Normal development meetings ought to serve the following purposes.

1. Communicate transparency from development to corporate. 
2. Communicate direction and prioritiziation from corporate to development.
3. Communicate present-status and next-step planning regarding a project.
4. Promote team-workload communication among team-members.
5. Six month employee review.
6. Deployment rehearsal.

 More on these later…

Mike J Berry
www.RedRockResearch.com

Having a technical background is an obvious advantage in terms of understanding the complexity dynamics the team deals with.  One big reality, however, is that these vast technical skills are only a subset of what is required to become a great manager, and the new manager soon discovers he needs to learn much more about the role.  

In Jack Welch’s book Winning, he explains that being a good leader means you shift the focus from you to them–from being the only one able to solve the latest problem, to being the proverbial “dumbest person in the room.”  Accountability should come hand in hand with empowerment.  Learning to empower your teams can be difficult, and seem like a leap of faith at first.  You soon learn, however, that letting your team originate the solution, predict the schedule, perform the work, and solve the problem builds their trust in you and in themselves.  

Another effective technique is to make your team accountable to the executive staff themselves–in person–instead of you being the go-between, shielding them.   Have the team leads accompany you to the Executive Committee meeting to report their progress.  This way, they can feel a sense of accomplishment for their victories, and feel the pressure from the top, instead of from you!  Teach them to be commitment oriented.  Develop a commitment-oriented culture by keeping track of their commitments and holding them accountable for each one.    Base their bonus structure on their ability to keep their commitments.  This will teach them to be more accurate, which translates into better predictability that that is better for everyone. 

Joel Spolsky has a simple solution for this.  It’s called Evidence Based Scheduling and you can read about it here.

Mike J Berry
www.RedRockResearch.com

Fortunately, software development management requires a smaller skill-set.  Software Development Managers really have four areas of responsibility.  These four areas are:

1. Responsibility to the corporation
2. Responsibility to the development department
3. Responsibility to the customer
4. Responsibility to the product

To the corporation, the development manager owes efficient yield,  predictability of delivery dates, and transparency regarding the health and status of each project.  

To the team, he owes corporate transparency (what goes on in the executive meetings), clarity of direction, priority of tasks, empowerment, and accountability.  

To the customer, he owes the highest reasonable product quality, and highest reasonable product relevance.

And to the product, he owes the best tools, architectures, and programmers he can find. 

Mike J Berry
www.RedRockResearch.com

Think about these as numerator and denominator drivers.  Together they make a formula that looks something like:

  Yield(Investment)  x Market Opportunity x Accessibility
  ———————————————————————————–
  Cost of (Development x Support x Sales & Marketing x Admin)

So, the basic idea, for a software company, is that if you have frequent software enhancements and new products that match a ripe market opportunity, and you let your customers know about it, then you can collect a lot of top-line revenue.  The trick is to do this while spending the least amount on the bottom line. 

What’s interesting about this process is that bottom-line cost is somewhat predictable and standardized.  Meaning, it costs your company probably the same amount of money to hire a development manager and to get a building to put people in as it does the company across the street.  In order to shave expenses from the bottom line, you need to understand every competitive advantage your competitors have and newer industry trends in technology and implement them yourself as much as possible. 

The numerator factors are really what’s unique about your products or services that set you apart from the competition.  The more relevant these are to the existing market appetite, and the more your customers know about them, the faster your top-line will grow. 

Now, wasn’t that simple?

Mike J Berry
www.RedRockResearch.com

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

Here’s how it works.  Your Executive Staff meets every two weeks.  You produce a list of all the hours available that your programmers collectively have for the upcoming two weeks (minus vacation, etc).  You produce a second list of ongoing projects, pending projects, and then you offer up the floor to whomever wants to request new feature X, Y, or Z.  They get to justify their request to the whole Executive Staff, preferrably on paper, and then the whole staff decides when to start on the new project, and how to prioritize it. 

This way, project requests get presented and evaluated against the opportunity cost of the other projects, and not based on urgency or theatrics.  There’s a little more to it, but this basically describes an effective solution for an age-old problem.

Mike J Berry
www.RedRockResearch.com

To my amazement, the forward commentary is by Gary Crittenden, a long-time friend of mine.  Gary and I lived near eachother in Munich, Germany years ago.  I believe my girlfriend at the time was a nanny for his kids.  He led a group of us on a 5 day bicycle trek across Austria.  Amazing experience.  We went skiing together often in Der Schweitz.  Gary worked for Bain at the time, and later was the VP of American Express, and now has the CFO chair at CitiBank.  (If your reading this, Gary, Here’s a big ‘Hello!’) 

I’m eager to read the book because it details the challenges, solutions, and results American Express faced as it went through a Portfolio Management Revolution.  Internally, they call the process Investment Optimization (IO), but it is known throughout the industry as Corporate Portfolio Management (CPM).  This process scales very well to the software industry, except that only about 50% of all software companies in America have any kind of Portfolio Management process.  Of those, few target Customer Value as the main driver for success.  So there is a lot of work to be done in the software development industry in this area.

Mike J Berry
www.RedRockResearch.com

Mike J Berry
www.RedRockResearch.com