The ADKAR model is a popular change management framework that helps individuals and organizations understand the stages of change, and how to manage change effectively. The ADKAR model was developed by Jeff Hiatt, the founder of Prosci, a leading change management firm.

ADKAR is an acronym that stands for:

1. Awareness: This stage involves creating awareness about the need for change among the people who will be affected by it. This includes understanding the reasons for the change, the benefits of the change, and the potential impact of the change.

2. Desire: In this stage, individuals need to have a desire to support the change. This involves understanding why the change is necessary and how it will benefit them and the organization.

3. Knowledge: Once individuals have a desire to support the change, they need to acquire the knowledge necessary to make the change successfully. This includes training, education, and communication about the change.

4. Ability: In this stage, individuals must have the skills and ability to make the change happen. This may involve providing additional resources, tools, or support to help people adapt to the change.

5. Reinforcement: Finally, in this stage, individuals need to be reinforced and rewarded for making the change. This includes recognizing and celebrating successes, and providing ongoing support and encouragement to ensure that the change becomes a part of the organizational culture.

The ADKAR model is a useful framework for managing change because it focuses on the individual level, and helps to ensure that people have the necessary knowledge, skills, and motivation to make the change happen. By following the ADKAR model, organizations can increase their chances of success and achieve their desired outcomes.

The Hidden Factory is everything your group does over again because it didn't go right the first time around.

This ranges from re-doing a failed multi-year project, to re-pushing a production release which had some minor issues the first time around. Sometimes these activities are called "Fire Fighting."

Most groups I talk to tell me that about 35% of their teams efforts are lost to this problem.

Someone must pay for this, and it's very expensive.  Higher prices, lower wages, and lower shareholder dividends are one way to quantify the hidden factory.  In addition, the opportunity cost of not being able to reach your project monetization goals 33% faster means you left money and customers on the table.

The Stable Framework™ is a performance management framework for IT designed to give IT departments the tools needed to tame this wild Hidden Factory beast and bring the fire-fighting down to nearly zero, where it should be.

Read more about it here

Mike Berry

There are several project management methodologies and practices to choose from, and the best approach depends on the specific needs and goals of the project. Here are some of the most popular project management methodologies and practices:

1. Agile: Agile is a flexible, iterative approach to project management that emphasizes collaboration, adaptability, and delivering value to the customer. Agile methodologies include Scrum, Kanban, and Lean.
   
   
2. Waterfall: Waterfall is a linear, sequential approach to project management that involves completing each phase of the project before moving on to the next. It's a more traditional approach and is useful for projects where the requirements are well-defined and unlikely to change.
   
   
3. Stable: The Stable Framework™ is an Operational Excellence model for project management and operations that can be combined with Agile, or can be performed stand-alone.
   
   
4. RINCE2: PRINCE2 is a project management methodology that provides a structured approach to managing projects, including defined roles and responsibilities, a focus on the business case, and a step-by-step approach to project delivery.
   
   
5. PMI's PMBOK: The Project Management Body of Knowledge (PMBOK) is a framework developed by the Project Management Institute (PMI) that provides guidelines for managing projects across a range of industries and project types.
   
   
6. OPPM: The One Page Project Manager is a spreadsheet-based approach to Project Management.
   
   
7. VI Sigma: Six Sigma is a data-driven methodology that focuses on improving processes and reducing defects in products and services. It's often used in manufacturing and other industries where quality control is critical.
   
   

In addition to these methodologies, there are several project management practices that can help ensure project success, including:

• Defining clear project objectives and deliverables
• Establishing effective communication channels and regular project status updates
• Assigning roles and responsibilities to team members
• Developing a comprehensive project plan and schedule
• Identifying and managing risks throughout the project
• Monitoring and controlling the project's progress against the plan

Ultimately, the best project management methodology and practices will depend on the specific needs and goals of your project. It's important to assess the unique requirements of the project and choose the approach that's best suited to meet those needs.

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

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 ke copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

I value Excellence over Heroics.

'Excellence' can be defined as "the crisp execution of established procedures."  Think about that for a minute.

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

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

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

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

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

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

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

Mike erry
www.RedRockResearch.com

A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.

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

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

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

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

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

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

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

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

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

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

1. The team or corporation has a deep passion for the subject matter of the opportunity.


2. The team feels they can become the best in the world at it.


3. The opportunity is in-line with what drives the corporation's economic engine.

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

Mike J Berry www.RedRockResearch.comWith a forward by Zig Ziglar, John C. Maxwell's book titled The 21 Irrefutable Laws of Leadership is an assured home run.

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

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

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

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

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

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

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

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

1. Gathering customer insight about a software product should be mandatory.


2. Structuring code in re-usable formats (classes) will improve the effectiveness of the development group over time.


3. Keeping a library of UI artifacts and ideas can help a development team make decisions faster, and have a more consistent look and feel across a large project, or across multiple projects.


4. In the software industry, we often make the same mistake that the Detroit manufactures make by supposing quality is our final endpoint (ie: "Quality is Job One!").  We need to understand that relevance is different from quality, and we need to structure our processes to maximize and measure relevance, along side of quality.

Mike J Berry www.RedRockResearch.com

I 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 off re valuable take-aways.

Mike J Berry
www.RedRockResearch.com