Great Mission Statements

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Respect, Integrity, Communication and Excellence.”

Mike J Berry
www.RedRockResearch.com

Improving Employee Morale

As a software development management consultant, I’m always looking for innovative ways to improve employee morale.

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

Book Review: Under Pressure and On Time

Posted by mikeberry | Book Reviews,Leadership,Project Management,SDLC Management | Thursday 6 December 2007 11:30 am

Ed Sullivan’s book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.

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

Book Review: Software Project Survival Guide

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

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

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

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

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

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

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

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

Software Development Project Do’s:

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

Software Development Project Don’ts:

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

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

Mike J Berry
www.RedRockResearch.com

Book Review: Results

I finished reading Results: Keep What’s Good, Fix What’s Wrong, and Unlock Great Performance, by Gary L. Neilson and Bruce A. Pasternack.

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

Book Review: Integrating Agile Development in the Real World

Hooray, another book on Agile Development!

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

Agile Development and Government Contracts

Posted by mikeberry | Agile Development,Agile Executives,Project Management,Strategy & Portfolio Management | Wednesday 14 November 2007 10:20 pm

So I attended our SLC-based agile development forum yesterday.  Alistair Cockburn was there, along with some other associates from around the valley.

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

To Gantt or not to Gantt? That is the question!

Posted by mikeberry | Project Management,SDLC Management,Strategy & Portfolio Management | Friday 9 November 2007 5:21 pm

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

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

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

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

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

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

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

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

Mike J Berry
www.RedRockResearch.com

Meetings? We don’t need no stinkin’ meetings?

There seems to be no set standard for development meetings.  Some groups complain about being ‘meetinged to death,’ while others complain about a lack of communication, direction, or group cohesion.  Given the two options, it is generally agreed that overcommunication is much better than undercommunication.

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

Improving Accountability Within your Development Department

Posted by mikeberry | Leadership,Product Owner,Project Management,ScrumMaster,SDLC Management | Wednesday 31 October 2007 12:03 am

Many Software Development Managers find their way into the “coveted” position from atrition after being a development team lead, or senior architect.

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

« Previous PageNext Page »