Project Canaries


Yellow-fronted Canary (Serinus mozambicus)
Yellow-fronted Canary (Serinus mozambicus) (Photo credit: Wikipedia)

On my way home today, I heard a classic song from my youth, Canary in a Coalmine by The Police. This song reminded me of a book that I have found to be insightful and a concept within Business Transformation that is worth expanding upon here.

The book is Corporate Canaries: Avoid Business Disasters with a Coal Miner’s Secrets, by Gary Sutton. The premise is that just like coal miners used to bring canaries into their coal mines as a form of early detection system for poisonous gas, there are corporate canaries that can serve as a similar form of early detection system for corporate death or failure.

So, on my ride home inspired by The Police, I began to capture some project canaries, or project level warning signs that can show a toxic environment within your project, programs, or portfolios. Here they are in no particular order:

  • The business should make business decisions and technology should make technology decisions.
  • If you don’t have the business defined, you don’t know your destination.
  • If you don’t have a schedule, you don’t know when you will arrive at your destination.
  • If you don’t have “one throat to choke”, you don’t have any accountability.
  • If you don’t have organizational roles & responsibilities understood, you can’t make decisions.
  • The project can only move as fast as decisions are made, and kept.
  • If you don’t communicate, others will define their perception as your reality.
  • If you don’t manage your budget, you don’t have control.

Think of these bullets as canaries in your project. Find the shelf for them to prop them up and watch to see if they keel over. Keep your eye on them as you traverse your project environment, organizational culture, and hallway passages.

Advertisements

Organizational Capability for Transformation


Navy File Photo - President of the U.S. Naval ...
Image via Wikipedia

“You must never confuse faith that you will prevail in the end with the discipline to confront the most brutal facts of your current reality, whatever they might be.” – Admiral John Stockdale, USN.

How do you align the business with IT? How do you confront the reality of a business strategy when it represents a threat to the status quo? How do you align that direction with a portfolio of projects that incrementally deliver on the desired change? In order to transformation a business, company, division, or team, you need to assemble many disciplines and techniques including but not limited to: business strategy, enterprise architecture, project management, personal development, communication, and training.

There are many books, white papers, and commentary on business strategy, project management, change management, IT governance, and organizational design. However, I rarely see any transformational thought leadership that describes these concepts as organizational capabilities, or services that work together in unison. When teams have raised their capability to deliver multiple skills like this, they position themselves better for success.

In order to transform an organization, the organization needs to position itself for success by building the capability to change, or transform. Too frequently, leaders assemble only one or maybe two of the disciplines listed above to deliver significant change. Calling on Admiral Stockdale’s profound leadership, transformational leaders should have confidence in the 1 or 2 skills they have brought together to drive change, but they should also confront the reality that most transformations fail. Have you assembled all the skills and capabilities you need to be successful with your change? What additional capabilities does your team need to better position you for success? Confront your reality and adjust  your team to bring more transformational capabilities to the table.

Integrating an Enterprise Strategy and “The Agile PMO”


Blue Heron Bridge - Singer Island, Florida

The Agile PMO Role

So how do you integrate enterprise strategy and corporate performance into an agile delivery model? On one hand, the enterprise strategy and corporate performance require stability, predictability, and a high degree of structure, much like the Blue Heron Bridge in Singer Island, Florida. On the other hand, agile techniques are extremely useful with adjusting and reacting to uncertainty by creating highly collaborative environment and pushing decision making into daily scrum meeting / calls between project stakeholders. In my experience and discussions with companies and teams in this space, many view this as a holy grail. The article linked above by Tamara Sulaiman at Gantthead does a fine job of positioning a classic organizational capability, an Enterprise Project Management Office (EPMO) within an agile construct, and offers several ideas on how to make it work.

In particular, what I like most about this article is the clarity around specific activities and capabilities that could be put into place to make an Agile PMO live within a company. The most interesting capability in the Agile PMO is the meta-scrum. The article go on to say “the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.”

If you are leading a business transformation, implementing a corporate strategy, delivering a large program, or managing a project with multiple sprints, I see the following critical success factors for integrating agile within an enterprise strategy:

  • Articulate your strategy in a manner that is culturally acceptable for your company.
  • Decompose the strategy into a series of initiatives / programs / projects / sprints that can be understood by your company with traceability from the top of the company down to the first line employee.
  • Establish enough of a management system that embraces agile concepts at the daily execution level while gathering the basic information that will allow you to answer the hardest strategic level questions from your CEO. Basic elements that I propose include but are not limited to: corporate goals, programs / projects / sprints / tasks, employee hours worked on a weekly basis, & capital vs expense delineations.
  • Define and allocate executive level ownership of the corporate goals, programs, projects, sprints, tasks and associated budgets to move decision making as close to the source as possible.
  • Tooling to implement your management system so that you are not running your business in Excel spreadsheets.

In the end, you want to create a corporate ecosysem, think of this as a culture and management system,  that mimics the structure and stability of the Blue Heron Bridge (aka the enterprise) while allowing the daily variability and agility of the underlying ocean of change to ebb and flow (the people, programs, & projects).

Collaborating – Do you want to be happy or be right?


Have you ever found yourself in the place where you are debating one side of an issue and gaining no ground whatsoever? Have you ever asked yourself what matters more, being happy or being right?

In my change efforts, I frequently look for and, more importantly, listen for these two points. The next time you find yourself in a debate or a slight disagreement, try to determine if the other person is really worried about being right (e.g. I know the best way to do this and there is only one way, my way) or if they are willing to be happy and accept an answer that might be somewhat different than their current view. Its not always easy to hear the differences. A lot of time it comes down to emotions. If you can gain a perspective on their emotions, you will do yourself a favor. Here are a couple of my favorite questions to assess the situation:

  • What is the emotional state of the person debating me? Are they frustrated and driving to a point to prove themselves correct?
  • Ask “So what?” in a very genuinely curious fashion. Without being curious, you will sound (and be) arrogant. Asking this question is the best way to cut through the “noise” and distill the real underlying issues. HINT – you many need to ask the “so what” question multiple times until you get to the real root cause. Being genuine is the key here. NOTE – This cannot be taught. You are either genuine or not, and people can figure that out.
  • Is this person interested in my perspective? When I share my view is the person really listening to me? Or, are they just waiting until I pause so they can insert additional supporting reasons for why they are right? Ever heard of “active listening”? Do you use it? Do they?
  • Last, ask them the question of this entry, “do you want to be happy or be right?”. Be prepared for the “what do you mean, response?”. It may stop someone in their tracks, the first time. Then everytime thereafter, they will ask themselves the question and possibly preempt the debate in the first place.

In closing, being right usually feels really good to the individual “being right”. It helps the self-confidence. It becomes a self-fulfilling prophecy. After all, its nice to be right, isn’t it? It definitely beats being wrong! Happy, on the other hand, creates room in a team for others to be right, and it allows you to provide input without focusing on being right.

IT Governance Rule #2 of 3 – Make sure you are doing things right


In article 2 of a 3 part series on IT Governance, if you have a capability to make sure you are doing the right things (article 1), you need to make sure you are doing them right. With this entry, lets assume you or your organization know what matters most, and your focus is  in determining how to make sure your team delivers.

What matters more, an excellent strategy or excellent execution? If you had to pick one, which would you pick? In Making Strategy Work (2005 Wharton School Publishing – Amazon link here) Lawrence Hrebinak argues that execution of strategy is the key, not strategy definition itself. I concur and this means that this second rule is more important than rule #1, and my experience across multiple industries, countries, and economies suggest the same. It is amazing how delivery of solutions or eliminating problems “takes the noise out of the system”. In my consulting days, I was thrust into many troubled situations. In these situations my clients consistently said “if you can’t deliver on what I have already contracted to you, why do you think I would give you anything else?” Makes sense to me!

So, how do you make sure you are doing things right? Some considerations (in no particular order):

  • Project Management
    • How many projects are active? Is it easy to determine the answer? If not, you have an issue.
    • For each project, what are you delivering, when will you be finished, and how much will it cost?
  • People, Process, Technology
    • Do you have the right people in the right roles (as I type this the 2010 NFL Draft is on my TV in the background)?
    • Do you have the right delivery system or processes?
    • Do you have the right technical capabilities, architectures, platforms?
  • Relationships
    • How do the business and IT relate to each other at the enterprise, project and operational levels?
    • What does the business say about IT? What are the 10 adjectives that the business would use to describe IT?
    • What does IT say about the business? What are the 10 adjectives that IT uses to describe the business?
    • What is working well?
    • What would you change if you were King for a day?

To make sure you are doing things right, it doesn’t take a PhD. It’s really more about the basics. And, what is more basic, better said – universal, than a traffic light? Red, yellow or green? English, Spanish, German, French, Chinese, Japanese, or Australian we all understand the basics of red, yellow and green. Use these universal icons to determine if you are doing things right. With this vernacular in place, manage by exception. Be hard on the red items. Watch the yellow items. And, most importantly, determine which green activities are really yellow, and which yellow activities are really red and you will stay 5 steps ahead of your changes.

The Inter-relation of Project Management and Change Management


In my previous post here, regarding skills necessary for next generation project managers, I referred to an article on CIO.com. I also posted a question to multiple groups within LinkedIn (including but not limited to CIO magazine, Change Consulting, Leaders & Thinkers, Philadelphia Technology Group, Business Improvement, Change Management, and Turnaround, etc.) and the response has been overwhelming.

Many of you have agreed that there is a close link between project and change management. I decided to pull some of the better excerpts here.

  • I do believe that if you want to make important changes in an organization, a complete turn-around or a transformation, then it easily gets diluted if you do not run it as a project. Considering people’s adversity to change they will find every opportunity to avoid changes or go back to their former way of working. A project creates a solid framework, with measureable milestones, progress reports, focus on areas where change does not happen according to the objective, and subsequent corrective measures.
  • A project by definition is a special endeavour that is different from routine work. Anything which is new and people are not used to, will require change management for its effective implementation or delivery of its intended results. However, the scope of the project and its impact will determine the change management required. On the other hand Change Management is again by definition is something special and hence can be considered a project and needs to be run like a project even though some of the outcomes of a change management initiative are qualitative and difficult to quantify. More visionary leadership is required for a change management initiative.
  • Any change program of a certain magnitude must be managed as a project.
  • I totally agree that to change the mindset of the people really need people who have influence or leadership qualities ,who can drive the ideologies in such a way that people start accepting those ideas.The success of any Project lies on the shoulder of leader as to how influential or diplomatic he or she is to drive people for change without much resistance I agree that individuals need to have willingness to change but my experience is that Strong leaders first create strong team then show the positive aspect of the desired changes to people,influence people to accept changed environment,motivate people in such a way that they are willing to accept any change and then establish informal communication channel with grass root level people and then simply put across the formal roadmap of any Project.
  • Both Project Management and Change Management are disciplines. Both are managing a transformation from current reality to a desired future state. Any initiative that is responsible for the development and/or delivery of something significant will require a Project Manager to drive planning and execution. The question that most people struggle with is “when is a change management track required along with a dedicated Change Manager?” The answer lies with “behavior”. The more that the project’s deliverables require a change in human behavior, the greater the need for Change Management. (Ex. The delivery of new spreadsheet software to people who use spreadsheets, simply requires some user training. However, an initiative that changes business process and the roles, responsibilities and procedures expected of people is expecting new behaviors and requires more than training classes.)
  • Most projects are initiated to change something and therefore, change management should an integral part of what is done to ensure success.
  • The ultimate value of any project rests with how well the change is absorbed in the organization. All successful projects I have seen tend to have incorporated some level of awareness that the transition from the ‘as is’ state to the ‘to be’ state will involve change and have – to some degree – proactively planned for the need to understand and manage that change throughout the project.They should be joined by the hip. I can’t recall any project that I have run where the organisation I was delivering the project for wasn’t prepared for the implementation in terms of communication, training etc.
  • …it is hard to imagine any kind of significant change that would not benefit from being managed as a project.
  • Change is constant, project is the boundary we draw to manage it in a phased approach.
  • Project management is a discipline that is about delivering change. Organisational change management is a closely related discipline that is also about delivering change.
  • They are related inasmuch as you have many Project Managers who have been involved in “change” initiatives and many Change Managers who have been required to “project manage”. That said my view is that they should not be related but complimentary. Why? A Project Manager is the owner of a plan that is milestone driven whilst a Change Manager has the unenviable task of winning hearts and minds and changing culture which cannot be milestone driven. Ideally the PM and CM should compliment each other in the context of a project. First and foremost I am a Change Manager and my Project Management skills are secondary to what I do.
  • Change management is also studying the impact of any change. It is also about continuous re-inventing.
  • Formal plans and statements contribute to this process. But these consistently fail to address crucial aspects of real-world organisations that managers experience every day. Other, ever-present features of organisational life – such as the impact of power and politics, the importance of informal processes, and the implications of paradox – tend to be dealt with superficially or ignored altogether.

And, I am only through about half of the feedback! This is clearly a topic of interest across a broad group of individuals.

I believe the two modes of thinking are related, and probably best described as “co-dependent”. While some comments focused on technical change management, most folks articulated the concept of project management providing a “blocking and tackling” approach to driving incremental organizational movement in a direction that is different from where an entity is today.

I prefer to think of project management as one important technique to enable change. In itself, it is not sufficient. Project Management is effective as breaking up a large problem into smaller digestable pieces. My team and I have a saying to refer to this phenomenon “How do you eat an elephant? One bite at a time.” Some methodologies I have been exposed to encourage “a series of small successes.” These are all project thinking models that help us digest large scale changes.

Change Management (in the cultural / transformation sense) becomes necessary based on the magnitude of the change the project is driving. Sizing the amount of change, can be a challenge. I use the framework from this blog entry to contextually appreciate the change at the enterprise and project level. When more of the domains are involved, more change management is required.

In closing, I would like to share a final word on management vs enablement. In our transformation approach, we have implemented and built out a project management system (processes and tools) to manage the business and IT related projects. We are driving large scale change into a company using project management as one technique. We also realize that project management, while important, is not sufficient in isolation to drive a business transformation. A broader framework is required. We view Change Management as a broad all-encompassing concept with multiple capabilities required to conduct a successful transformation. Along side of program & project management, we are building out a “change enablement” capability as well. I am not convinced that one can manage change like one manages projects. In textbooks and theory, we can definitely defend an approach to managing change like managing a project. However, in reality, its not that “black and white”.

We are breaking down our business transformation into a series of measure outcomes using project / program management techniques and dealing with the softer aspects of change via change enablement. When the size of the change impacts are broader than the business capability and technical enabler domains, (ref. this model) a much more entrepreneurial model is being applied to address the strategy, cultural, competencies, and structural domains. Our enablement serves as the “grease on the corporate gears” and facilitates the highest level transformational direction which can then be programatically broken down into a series of small successes so that we are able to eat the entire elephant!

10 Key Capabilities of Next-Generation Change (Project) Managers


The 10 Key Capabilities of Next-Generation Project Managers – CIO.com – Business Technology Leadership.

Project management and change management are closely related. In fact, I view it more as project “thinking” and  change “thinking” that all people involved with business transformation need to embrace.

The behavioral attributes of project management, or “project thinking” transfer well into the arena of business transformation. With increased complexity comes the need for increased discipline. This has been a motto that I have shared for many years with my troubled project engagements. Business transformations mean increased complexity in the form of “more, better, faster, cheaper”. In this type of environment, project thinking becomes a rising star. The ability and (more importantly) willingness to pay attention to all the details and facilitating progress by segmenting (or what I like to refer to as “bucket-izing”) issues, actions, risks, dependencies, and decisions are but two of the key technical skills.

I like this article from CIO.com because it goes beyond the technical skills and provides a good list of leadership skills for the next generation or transformational project manager. Project managers need to have the basic technical skills, and then need to bring the skills outlined in this article to make a difference. If you find yourself operating as a PM within a fairly predictable environment (I am not 100% sure if these exist anymore) then these capabilities might not be so critical. However, if you are in a transformation or chaotic environment, I suggest that this is a very good list of capabilities, and one that we should leverage. Rate yourself on a scale of 1-10 for each of these capabilities, then define which ones you want to grow. We all have “flat spots”. Knowing them is half the battle.