Do Managers Truly Understand How to Measure Critical Success Factors (CSFs)?

Earlier this month, I spoke with James H. Dobbins about his latest book, Critical Success Factors: How to Effectively Identify, Measure, and Apply CSFs, which equips managers with a practical framework to accurately identify, measure, and apply their critical success factors (CSFs). Unlike previous efforts that relied on broad surveys and statistical analyses intended to generate generalized lists of CSFs, this approach honors the foundational definition of CSFs and provides actionable guidance tailored to each manager’s unique context.

During our conversation, I asked James, "What are the biggest mistakes managers make when trying to measure critical success factors (CSFs)?" Here is his complete answer:

The biggest mistake managers make when trying to measure critical success factors (CSFs) is failing to understand what CSFs are in the first place. Managers turn to the results of research by others, projects often done by academics in the pursuit of an advanced degree. The research objective is to produce a list of generalized CSFs.  Once the list is published, the research is completed, the degree is granted, and the researcher goes on with their life. No measures are suggested. Many researchers worldwide, all with the same objective, have published different sets of CSFs. There is no guidance on which list to use. The biggest problem is that all the research was conducted using surveys of large numbers of managers, and there has never been a valid list of CSFs produced from surveys. Using surveys to identify CSFs has several fundamental flaws.  Some, noted in the Introduction to the book, are:

• The assumption that project managers know how to identify their CSFs,
• The failure to recognize that CSFs are contextually relevant to the manager, and therefore, the elimination of anything not generalizable, is contrary to the definition of CSF.
• The failure to understand that Critical Success Factors are, in fact, critical for a specific manager, and that all must be done well.  CSFs are not something you pick from a menu, like a survey result, hoping you chose the right ones.
• The absence of any longitudinal studies. There was no follow-up with any of the managers surveyed to validate the study's results or to determine whether and how they utilized the CSFs identified in the survey.
• There was no attempt to identify measures for the identified CSFs to help managers track their success in meeting the CSFs.  

Does your company actively use and apply critical success factors (CSFs) in its operations? Does your organization rely on surveys to determine which CSFs to prioritize? And do you agree with the mistakes James H. Dobbins identifies in this area?

Why is the Failure Rate of IT and Change Management Projects So High?

 A few weeks ago, I had the chance to me with Scott R. Coplan in New York City and discuss the release of his new book, The Integrator: A Change Management Framework for Achieving Agile IT Project Success. This book defines change management as the single overarching methodology integrating Agile IT and project management. It does this because all projects are about change – significant organizational and personal change. The people involved – their participation in and understanding and support of these changes – ultimately determine IT projects success or failure. In fact, while all IT projects are about change, successful projects change human behavior.

During our conversation, I ask Scott, "Why is the failure rate of IT and change management projects so high?" Here is his complete answer:

There’s only one reason projects fail — leadership. You know who I’m talking about. Most of us have worked for that problematic project leader. 

Everything stems from a project’s leadership. They are the principal players or sponsors responsible for guiding each participant in completing the project successfully or failing miserably. 

A successful project requires a chain of sponsorship, including authorizing and reinforcing leaders. Authorizing sponsors have the power to approve, fund, and allocate resources to achieve a project supporting the organization’s clearly defined purpose. Reinforcing sponsors uphold, strengthen, and execute the project on behalf of the authorizing sponsor. 

The pervasiveness of project sponsorship problems stems from one fact. Just because an individual holds a leadership position doesn’t mean they know how to lead. They need guidance. 

In these instances, the problematic sponsor’s boss or a change agent must start by working with that struggling project leader. While having a meeting about their inadequacies is never easy, it is necessary. 

Most problematic leaders feel inhibited in a sponsorship evaluation meeting with their boss. As a change agent of 45+ years, I’ve conducted hundreds of meetings as the boss’s proxy.

This requires preparation before the meeting, including clarity about what the problematic sponsor must do, described in safe language. It’s typical for a sponsor to have little idea of what sponsorship means. I always start by taking time to listen and understand the problematic sponsor’s viewpoint, particularly about their role and what fulfills them in performing it. That sponsor’s input and my response may help them grasp the importance of their role and improve their performance. 

I’ve encountered sponsors that still don’t understand their role, requiring other options, like routinely assessing the sponsor’s performance and providing feedback. At times, I’ve recommended guidance from an effective peer in the problematic sponsor’s development process.

In severe cases, I’ve recommended replacing the sponsor. Their departure offers an opportunity for me to help the organization’s leadership find a suitable replacement. This is an individual who starts by engaging with their direct reports, establishing a shared purpose defined by enterprise-wide collaboration, followed by aligning their beliefs and abilities with that purpose. 

What do you think of Scott's perspective? Have your IT and change management projects been successful? Have there been leadership issues?

Implementing Change through Projects -- What are the Common Mistakes?

An impressive new book by Jeremy Nicholls, entitled The Everyday Project Manager: A Primer for Learning the Principles of Successful Project Management, explores the key attributes and skills of successful project management and describes the practical skills that will enhance project delivery regardless of your level of experience. In addition, Jeremy posits that success and survival in business relies on change and the way that business implements change is through projects.

At the beginning of the month, I spoke to Jeremy about his book and asked him: "What are the common mistakes made when trying to implement change through projects?" Here is his full answer:

Understanding the Context for Change

In the enthusiasm to get going and DO SOMETHING, organizations frequently fail to set a project within the wider business and strategic context.  Change via projects is easiest to implement, and more effective when it aligns with the overall background of change.  By considering the broader organizational goals and – importantly – how your project aligns to those goals, you will be better able to articulate the drivers for change.  This increases buy-in and significantly improves your change implementation.  When you think about it, this applies to personal projects too – your project to decorate the bedroom might be a great idea, but if your partner’s plan is to sell the house next year, they won’t support your change.

Identifying Champions

For change to be implemented most effectively, you require support up and down the organization. It seems to be stating the obvious to say that the more people who are championing your project, the more likely it is to succeed, but it is frequently overlooked. When people deliver projects, they tend to get very caught up in the nuts and bolts of the delivery itself.  It’s a different skill set, but one that the best project managers have, to get out there and engage with stakeholders and bring people along for the journey.  Your project sponsor is the key here; if they are not excited about the project outcome then there’s no reason anyone else should be.  But the main point is don’t just be a project manager – be a project cheerleader!

Get the Basics Right

There will be certain points during a change project where things get exciting.  This can be for a good, expected reason (the much-anticipated go-live), or a not-so-good, unexpected reason (an issue that threatens to derail the project).  In either case, when the temperature of the project gets to fever pitch, the first things to get side-lined are often the good (but not quite as exciting) practices that keep a project on track.  Stay focused on the objectives; remember the reasons for doing the project in the first place.  Avoid the tendency, to throw the baby out with the bathwater when the project hits a bump.  Go back to first principles, take a breath, and keep going.

What are your thoughts on Jeremy's perspective? Has your company been successful implementing change through projects? What attributes do you think compose a successful project manager?

Lean System Management -- Can Structured Systems Unify and Align Quality Practices Throughout an Organization?

It has been argued that that the proven practices of performance excellence and quality cannot be sustained over the long term. A new book by Richard E. Mallory entitled Lean System Management for Leaders: A New Performance Management Toolset postulates that the reason for this failure is that there is no cohesive guidance on the management of groups of people working together toward specific goals. The author believes we currently have only a patchwork of two very specific knowledge areas -- one for process management and one for project management. I asked Richard a series of questions about how his book seeks to rectify this situation. I'm including those along with Richard's very interesting answers here:

Why do you believe that system management is new to management?

System management shows how to create and define a best practice ‘map’ for any or all management systems, and how to identify and define its influencing factors of success.  This allows manager to create an operational best practice map with measurable metrics and indicators of success.  Once that is done, the model itself provides a foundation of a perfect ‘learning organization’ that can review and improve on its practices over each performance cycle.  There is nothing in existing management practice that shows how to provide this kind of structure, evaluation, and learning for the management structure overall. 

Why do you call it a “fundamental” body of knowledge for all managers?

Much of current management literature is focused only on one-to-one interactions with individuals--“supervision“-- or generic group practices like “motivation”, “goal-setting”, “employee engagement”, or “encouraging the heart.”   Another approach puts its focus on generic organizational frameworks that provide a cookbook of advisory or prescriptive tactics under headings like “Baldrige”, “ISO”, or “The House of Lean."   It is a great omission of current management knowledge that there is firm structure for defining, analyzing, standardizing, or implementing best practices for the specific practice areas of individual managers – either for a program office or for specific management functions like governance, strategic planning, budgeting, quality control, and project management.

Isn’t systems management mentioned in a lot of management books?

Yes, many books use the plural word ‘systems’ with the same meaning as an organizational environment.  One business book says that “systems thinking is more of a concept than a tool,” and describes the system as ALL the factors that surround a process.  Another calls systems “a set of inter-related processes.”  Either definition will blind managers to the possibility of documenting and improving a SINGLE area of management practice with specific goals – the real definition of a system.  When systems are looked at one at a time, it is possible to define and map their primary activities and success factors, and this kind of documentation of systems redefines management. 

What is the difference between a process and a system?

A business process uses a specific set of sequential steps, each of which can be defined, to produce a specific output with a definable set of output requirements.  A process is often completed by a designated work team, and is designed to be done the same way with the same sequential steps time after time.  A system is more easily seen as a project, in that it produces a valuable output but will have a production cycle that may not be rigidly sequential, that is more changeable because of intervening factors in each cycle, and that may produce a number of outputs all of which cannot be defined in advance.  A system is less likely to follow a single predictable path and may have to obtain its result using personnel that are not a designated work team. 

Given all those differences, what makes you think that a system can be mapped?

All human knowledge is based on science, which itself is based on observation of repetitive cycles and learning about the factors that drive success in any given cycle.  If you start with the premise that each management system is cyclical and has quantifiable goals, then we can define and predict the principal activity groups (or milestones) that are necessary to achieve those goals. We can also then define the measurable attributes of success in each group.  Using cause and effect analysis, we can further break down the influencing factors (or “causes”) of success, and the metrics or indicators that can be seen when those practices are followed.  Even though the operational best practices of system are not sequential with specific assignable steps, the system map does provide a documented operational plan that can be evaluated and improved.

 

Can you explain the concepts of “native systems” and “design systems” that you refer to in your book?

Often times groups of people develop a habit, understanding, or “culture” about the way things are done around here, and this is the native system.  Like standing in line at the grocery store, people make things work based on assumptions of what is considered fair or right.  The same is true in larger organizations, so the way that we operate a program office, develop a budget, or decide on projects is often a combination of guess work and detective work.  The idea of design system is a deliberate decision of a leadership structure that for critical management outputs, there should be a focused effort to define how it will work best, to let everyone know about that operational plan, to evaluate its operation at the end of each cycle, and to innovate and improve based on learning.  This mirrors the practices recommended by the Framework for performance excellence of the National Quality Award that management systems should have a documented approach and deployment combined with periodic learning and innovation. 

The book title mentions Lean.  Does that mean if follows established process improvement methodology?

System management shows leaders how to achieve superior leadership results by applying a Lean DMAIC (Define, Measure, Analyze, Improve, and Control) structure to leadership systems and program office operations.  It shows leaders how to align and evaluate these systems using a Lean approach, and how to evaluate and score the maturity of management practices through the American Society for Quality System Management Standard (http://asq.org/gov).  It offers analytic skills to eliminate duplication and waste of executive and senior management time, and reduce the wait time and non-value add in dependent processes.

Explain how lean system management provides an agile framework for organizational change.

Lean system management presents a structured framework for defining and controlling organizations, along with a system maturity standard that allows regular measurement of the maturity and capability of defined management systems.  In this way it provides an agile framework for the organization-wide practice of quality (which we will refer to as “Performance Excellence”), and enables the use of a system maturity scorecard, showing the capability and maturity of quality management function throughout the organization.  It also allows and enables an organization-wide scorecard on the practice of quality at the process level, through use of the Process Management Standard (See Measuring Maturity, Quality Progress, Sept. 2016 --

http://asq.org/quality-progress/2016/09/process-capability/measuring-maturity.html).

What do you think of Richard's view of system management? Do you agree with his views on why performance excellence is currently not sustained by many organizations?

Team Building Using the Workforce Engagement Equation

Jamison J. Manion published a book titled The Workforce Engagement Equation: A Practitioner’s Guide to Creating and Sustaining High Performance, and I recently had the chance to ask him a few questions during a phone conversation. I wanted to know why he developed The Workforce Equation.  Specifically, I asked him: "What value would practitioners gain from investing their time to learn standardized approach to team building outlined in The Workforce Engagement Equation?”  Here is Jamison's response:

The pace of change in today’s world is staggering; it’s hard to keep up with all the technological advances.  To remain competitive organizations are incessantly driven towards process improvement.  Practitioners in every field must continuously sharpen their skills to remain relevant.  What’s more, every field is becoming more and more specialized.  People aren’t just programmers anymore; there are programs just for mobile apps, programmers for the healthcare industry, industrial drives, PLCs, ERPs and CRMs, etc.  Every field is becoming more and more niched.  But, regardless of the industry, the human element lies at the heart of every change initiative.  Post-project analysis consistently confirms that human factors, more than any other single element, are at the root of poor performance and failed change initiatives.  So, regardless of the industry or business sector, successful change agents must understand the human variables involved in implementing change in order to effectively utilize their in-depth professional expertise. 

Where do you begin? If a practitioner wants to gain expertise in managing the human elements there is a virtually endless supply of literature about leadership, change management, communications, conflict resolution, engagement, productivity improvement, performance improvement etc.  It becomes overwhelming; people just don’t have the time.  They end up picking up techniques here and there as they have time and apply whatever they can.  Like the old adage says, 'The solution to any problem you face is the one you happen to know.'  It’s all very piecemeal.  Consequently project success relies too heavily upon chance and circumstances – hoping that the problems that arise fall within the solution set available.  Speaking for myself, I became very frustrated that so much of the advice available was overly simplistic, nonspecific non actionable, and redundant.  I wanted a solution I could apply in my own practice on real-world problems and projects. 

Analysis of the research and personal experience observing how people learn, how teams form, what drives behavior, and how people make the transition from involved to engaged, revealed some consistent behavioral patterns.  To simplify the patterns I built upon the work of past practitioners and applied systems thinking to define the five stages of organizational development that resulted in The Workforce Engagement Equation:

Forming à Focusing à Committing à Sustained Performance à Renewal

Each phase represents a juncture where the team will either successfully navigate the situation to move to a higher, more cohesive level of group dynamics and operational performance or they’ll stumble, experiencing confusion, frustration, and lower productivity. 

Each stage requires appropriate management and leadership interventions to simultaneously satisfy the needs of both the project and the team.  The comprehensive change management approach addresses:

·       People Needs

·       Effective Management Responses

·       Effective Leadership Responses

·       Tools and Techniques to Employ

Understanding the logic model prepares practitioners to recognize the patterns and empowers them to adapt their response to successfully navigate the phase.  Regardless of the industry or the size of the team, understanding The Workforce Engagement Equation will equip practitioners to achieve success more consistently and in shorter time. 

What do you think of Jamison's response?  How often have you been frustrated by the human factors involved in project management or process improvement?

What are We Learning from Our Projects?

Recently, I had the chance to speak in person with Dr. Willis Thomas, author of a new book published in November 2011 titled The Basics of Project Evaluation and Lessons Learned. His book provides the framework to conduct lessons learned using the Project Management Body of Knowledge (PMBOK) as a standard.

When I asked Willis why he chose the PMBOK approach for lessons learned he replied:

Project managers trust and are comfortable with the PMBOK for five Process Groups (Initiation, Planning, Executing, Monitoring/Controlling and Closing) and nine Knowledge Areas (Communications, Cost, Human Resources, Integration, Procurement, Quality, Risk, Scope and Time). Many project managers run projects using these categories.

The approach I take is very simple; to overlay what has been done right, done wrong and could have been done differently using these 14 process group and knowledge area categories. This matrix, creates a 5x9 table of 45 categories, with three variables per category (right, wrong, differently), which results in potentially 135 elements for review.

This compartmentalizes the collection process for lessons learned so that it is situation-specific. The project team can then determine what lessons to review -- that is, what went right during project initiation regarding communications. Of course, each factor should allow for comments to detail characteristics of the lesson.

A primary goal for lessons learned should not only be to avoid making the same mistakes in projects (summative reflection), but to strategize for improvement (formative thinking). This approach can help project managers to be consistent in their approach to evaluating projects.

What do you think of Willis' advice? Have any of you used this process?

To Be, or Not to Be... A Project Manager

At the recent Association for Manufacturing Excellence (AME) conference in Dallas, I had the chance to talk with Adil Dalal, author of a new book called The 12 Pillars of Project Excellence: A Lean Approach to Improving Project Results. An important part of his book essentially provides the "5 Powers" needed to transform from a project manager to an advanced project leader. In addition, it provides groundbreaking techniques to achieve excellence in project leadership that can result in six sigma type results or failure-free projects.

I basically asked Adil what it means to be a project leader instead of a manager, and here is his response:

A project, by definition, is a "temporary" endeavor undertaken to create a "unique" product, service, or result. Thus, every project is like an expedition through the unknown terrain to reach the summit of success. When something "unique" is being created – how can we expect to manage it? Are we not required to lead the "unique" transformation effort? Today, most project managers fail because there is too much "management" and too little "leadership" during the journey. Only project managers who undergo a paradigm shift and transform themselves into project leaders by providing guidance and direction to their team can be truly successful in their expeditions every time. Attempting to manage a project is like trying to hang on to the tail of a wild tiger. The focus is always on countering the tiger’s every move to avoid the fatal jaws. Thus, a project manager is constantly in a reactive mode and there is no time for creativity. On the other hand, leading a project is like riding a tame tiger. Although there is a healthy level of anxiety and adventure, the focus is on guiding it in the right direction. Thus, a project leader is always proactive.

What do you think of Adil's ideas? What characteristics do you see lacking in most project managers? Does your organization have more project managers or project leaders?

Book Talk: Supply Chain Project Management

The devil may be in the details, and for those whose job is managing and optimizing their supply chains, Supply Chain Project Management, Second Edition: A Structured Collaborative and Measurable Approach is a book that can help tackle that devil.

Written and updated by James Ayers, a member of the Project Management Institute and the Council of Supply Chain Management Professionals, the book covers how to implement project management best practices in ways that will encourage continual improvement of the supply chain. It encompasses supply chain foundation concepts, ways to define supply chain and supply chain management, and effective SCM project processes.

It also highlights examples of how collaboration can reduce material and process costs. This book is scheduled for publication later this month.

Do you have a question or comment about a book(s) that you would like addressed in Book Talk? Email me directly at Ralph.bernstein@taylorandfrancis.com.