Comments Off

Hi All,

One of the researchers at CAI provided me this post and an article that you might be interested from Bob Galen.  I would be very interested in how you are using measurements / metrics within your Agile projects.

———————————————–

In the past, we’ve explored Agile methods. One of the key issues is – how do you know what to measure for an Agile development team?

In his article, “The ‘Essence’ of Agile Metrics,” Bob Galen explores the metrics that are helpful and injurous to an Agile team. To develop his list, Galen took the following approach:

I’m thinking of it from the point of view of what you’re trying to improve. In this case, your[sic] measuring estimates and actuals to improve your overall planning and estimation processes. These activities are typically front-loaded actions and are often static…meaning they are completed once at the beginning of the project. Read More>>

If the team is aware of their performance and how they are being measured, will they focus on continual process improvement, a key for functional agile metrics. What are your thoughts? Leave a message to continue the discussion.

Hi All,

Seems like there is a movement afoot to diminish the significance of having a Certified Scrum Master (CSM) title.  I ran across an article on www.AgileScout.com – Denounce your CSM - that is quite critical of the entire Agile Alliance and the Scrum Master Certification program.  Apparently there is a new kid on the block that is seeking to improve this business of certifications and training.  This newcomer is the International Consortium for Agile (ICAgile).   I was intrigued by the purpose statement that they have posted on their website:

Our Purpose

ICAgile’s goal is to foster thinking and learning around agile methods, skills and tools. We understand the difficulty of balancing education and certification, so as an alternative to other certification programs, ICAgile certification is skills based and requires people to demonstrate they have learned both why (the value) and how (the mechanics) for a core set of skills.

Going beyond validating skills, we will challenge people to use their skills to produce meaningful software products that can adapt to the changing needs of the users and their context. We will avoid a singular focus on process and techniques, which deliver substance (software) without meaning (value to the users). All courses will challenge people to apply what they are learning as tools for discovering real product value and how to best balance technology, skills and delivery to meet the needs of the market and the investors (sponsors).

-Reference ICAgile Website

The ICAgile has supposedly created a roadmap that guides aspiring Agilists in embracing the fundamentals of Agile development in a way that is reported to be more extensive than just spending a couple of hours in a classroom.    ICAgile has posted a roadmap on their website to help guide your agile education from a novice level to experienced in three stages. The three stages are:

International Consortium for Agile

-Reference ICAgile Website

Many of the readers of this blog have their CSM.  Tell me what you think about the latest criticism of the CSM program, Agile Alliance and the up-and-comer…ICAgile!

Pete

Rework.

Posted: 4th March 2011 by Peter DeYoe in Leadership
Tags:
Comments Off
I wrote a quick review of the book Rework on my LinkedIn profile.  I wanted to share with you.
Halfway through but I have to say…Smoking Hot Book. Just started it tonight. Can’t stop turning pages. AWESOME Read. Will question everything you do!”
 
Rework

Pick this book up and think about it in relationship to your Agile software projects.

Pete

Comments Off

Failure  is such a nasty word. We use failure to describe the end result of something. But with the advent of Agile Software Development techniques, we have changed the paradigm. Software development is no longer about beginnings and endings. It is about developing an evolutionary approach to the delivery of business value through software. It is a continuous process of successive approximation that will lead only to success over time. We have to stop thinking about software development as projects with defined starts and ends and instead think of it as continuous cycles of value delivery that respond to changes in the world, our businesses and our customer needs.

Are you just executing one-off projects using Agile with varying degrees of failure to success?  Or are you building value through a continuous software development capability that just keeps getting better and that responds immediately to the demands of your business?  Let me know what you are doing!

Pete

Comments Off

Hello All,

As you might remember from my previous article, we were reviewing the lesson’s learned that are covered in Jim Dempsey’s Webinar presentation entitled “Agile Lessons Learned.”   His next webinar is currently scheduled for May 17th, 2011.  Click here to register for Jim’s Webinar on the ITMPI Website.  To see a full listing of the scheduled webinars in 2011 through ITMPI go to http://www.itmpi.org/webinars.

If you remember, Jim’s webinar presentation identifies 19 lessons that he has learned over the past five years implementing Agile development projects.  In my last post, Reducing Risk and Avoiding Pain – Agile Lessons Learned (Part 1) we covered the first 3 lessons:

  • Lesson 1 – Agile is Difficult
  • Lesson 2 – You Need an Evangelist
  • Lesson 3 – Train the Business

In this article I will cover 3 more of Jim’s Lessons Learned:

  • Lesson 4 – Determine if your project is a good candidate for Agile
  • Lesson 5 – Prepare the Product Backlog before Sprint 1
  • Lesson 6 – Build a Release Plan

Lesson 4 – Determine if your project is a good candidate for Agile.  I bet you thought that Agile was the solution to all of your project needs!  But the truth is, Agile is not always the answer.  If the organization is not ready for an Agile implementation, there is a strong chance that it will not be successful.  A number of key factors must be considered in determining if the project is a good fit for Agile.  Some of these are:

  • Sponsor/Executive buy-in
  • Team buy-in
  • Team’s experience using Agile
  • Team size
  • Level of geographic distribution
  • Level of expected requirements change
  • Availability of customer resources to support Agile
  • Requirements familiarity
  • Regulatory requirements
  • System complexity
  • Technology familiarity

Construx Software developed a scorecard for determining if your project is a good fit for an Agile implementation.  This type of scorecard should be considered prior to any project initiation.

Lesson 5: Prepare the Product Backlog Before Sprint #1.   You might be inclined to begin developing your Product Backlog during the first Sprint Planning Meeting.  We made this mistake in some of our early projects and got us off to a rough start.  You should hold a separate planning activity to create your Product Backlog prior to the start of Sprint 1.  This should be done with the Product Owner and the entire team should be involved in estimating using a technique like Planning Poker.  The initial Product Backlog should then be prioritized and each story should have a clear statement of what constitutes “Done” for each of the stories.

Lesson 6: Build a Release Plan. Engaging in an Agile project does not mean that you throw planning out the window.  In fact, that could not be further from the truth.  We do an enormous amount of planning in our Agile projects and one of these plans is the Release Plan.  Alistair Cockburn states that:

The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate. Release planning answers the questions, “How can we turn the vision into a winning product in the best possible way? How can we meet or exceed the desired customer satisfaction and Return on Investment?” The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.”

In creating your release plan you should consider the following key points:

  • The Release Plan will be used to determine if the project will generate enough ROI to make it worthwhile;
  • You should specify a Release 1 Go-Live Date;

–      Fixed date determined by business, or

–      Date determined by projected completion of critical functionality.

  • You should continually revise and refine the Release Plan.

In part 3 of this series, we will cover the next 4 Lessons Learned from Jim’s Webinar series:

  • Lesson 7 – The Sprint Planning Meeting will Make or Break the Project
  • Lesson 8 – Manual Tools and Techniques Work Great
  • Lesson 9 – Requirements are Still Important
  • Lesson 10 – People are More Important than Process and Tools

Have a great week!

Pete

Comments Off

Hi All,

ITMPI has released 2 new webinars that I thought you might find of value.  They are available for FREE until February 20th.

Pete

—————————————–

Webinar # 1: Lean Project Management

Speaker:  Nick Spanos

Abstract: This webinar with Nick Spanos discusses how we can apply Lean concepts to project management to reduce costs while improving quality and value to the business. 

Register: http://solutions.compaid.com/forms/webinarfree?Event=Webinar_20110201A

 ——————————————-

Webinar #2: The Race to the South Pole: Lessons in Risk Management for Leaders

Speaker:  Rick Brenner

Register: http://solutions.compaid.com/forms/webinarfree?Event=Webinar_20110202A

Agile Adoption Equals Mental Shift

The adoption of Agile software development principles requires serious adjustments to the mental models we employ in approaching projects and understanding real business value.  Too often Agile adoption efforts begin with a focus on the mechanics of Agile (i.e., formation of a Scrum team, learning how to build a burn down chart, how to hold a daily scrum meeting and how to engage in sprint planning) rather than focusing on the principles of Agile.  Yet it is embracing the principles of Agile that will lead to success.

When assessing whether an Agile approach to a project will be successful, the first question we have to ask regardless of the size and scope of the project is whether the business is ready for an Agile implementation.  Agile does not just impact the IT organization.  It must be embraced by the entire enterprise.  We cannot for instance just create Scrum teams in an IT vacuum and expect to be successful.  We have to teach the business owners, stakeholders and IT folks alike the value of Agile and thereby change the way they think, act and measure success.  If they are unable or unwilling to accept these changes then you are probably better off with a more traditional model.  For instance, a mental shift must occur in how the business develops a project’s charter, scope, plan and budget.  In order for Agile to work successfully, we must stop asking the following question:

We have all of these needs and wants for the new system that have yet to be defined in detail but can you tell me precisely how long it will take and how much it will cost?(Traditional fixed-price model).

Instead, businesses looking to adopt an Agile software model must shift their thinking and begin rephrasing their question as follows:

“I can afford to spend $1,000,000 of my budget this year on the development of new software that will add value to my business.  How much real business value can I deliver this year for that level of expenditure?”

When operating according to the first question, an Agile software project (or perhaps any software project) is set up for disappointment and possible failure.  Inherent in the first question is the compilation of a list of needs and wants that have varying degrees of business value and that will ALL be included in a project plan, ALL be elaborated, ALL be designed and ALL be deployed regardless of real value.  What you then have is a project that drained $1,000,000 and is delivering a collection of functionality that runs the spectrum of business value; from unnecessary, to marginal, to great value.

In contrast, when operating in conjunction with the second question, the business can stand up and accept the challenge of prioritizing all of the perceived needs and wants, and deliver the most valuable business components possible for the $1,000,000 budget. Agile seeks to deliver only those things that are directly tied to real business value.  A well-known statistic in the industry is that 45% to 60% of the features and/or functions manifested in source code in a development project are rarely or never used.  In Agile, we seek to eliminate those features and functions that do not return true value to the business.  Many business and IT people have a real problem with this concept and have learned to believe that the project is not complete until all of the requirements that were specified up front have been coded.  But in reality, for most software projects anyway, many of the features and functions specified up front really do not contribute to TRUE business value and are in fact a waste of time and money.

A second Agile adoption principle that must be embraced requires businesses to stop thinking about software projects with defined beginnings and endings, and think instead of software applications as living, breathing, business-value delivery systems.  Businesses must understand that business value delivery through software is evolutionary.  As the business changes, so does the definition of business value and so must the software applications that deliver that business value.  One reason that most organizations have many applications that are developed, supported and then completely rewritten or replaced is that the system was typically conceived, built and implemented in a big bang approach that only served the needs of the moment.   But what if our mindset at the beginning of a project focused on organic growth and “evolutionary, business value delivery” instead?  If the software application was built from the beginning to accommodate growth and changes in the business then perhaps the need to completely rewrite applications in the future would disappear.

An Agile approach drives us to break down our software development into short phases or sprints which maximize the amount of business value (by way of features and functions) that can be delivered in a set period of time for a set budget.  We view it as a continuous process of:

  • Looking at how much we can afford this year (or in some prescribed time frame) on software that will deliver real business value,
  • Identifying those things that will deliver the greatest value within the budgeted dollars,
  • Elaborating, designing and building (just-in-time) in short iterations only those things with the greatest value,
  • Demonstrating that value to all stakeholders in working software (meaning it is potentially production ready) every 30-45 days (we use 30-day iterations typically),
  • Learning from each iteration to improve the process and product,
  • Testing for quality from day one (continuous integration, daily builds, test plans/scripts, automation, etc)
  • Reprioritizing features and functions every 30 days based on changing business needs.

Taking shortcuts, or believing that you can create some type of hybrid methodology at the expense of the key principles of Agile will simply lead to frustration and failure.  Agile software adoption MUST focus on the PRINCIPLES rather than just the practices if it is to be successful.

Follow me on Twitter at www.twitter.com/peterdeyoe

Hello All,

I hope that after one month into this New Year you are well underway with accomplishing all that you set out to achieve in 2011.  I am already noticing that the lethargy of last year has broken and businesses are starting to look at strategic projects.  If this characterizes your company, perhaps you are starting to prepare for new software development initiatives using Agile as your guiding principles and methodological framework.   If so, one of my colleagues, Jim Dempsey has compiled a list of “Agile Lessons Learned” that might help you in your planning activities.  With his permission, I will share some of them in this article and upcoming blog articles.  You should note that Jim gives his entire “Lessons Learned” presentation in a webinar that you can attend for FREE.   His next webinar is currently scheduled for May 17th, 2011.  Click here to register for Jim’s Webinar on the ITMPI Website.  To see a full listing of the scheduled webinars in 2011 through ITMPI go to http://www.itmpi.org/webinars.

In Jim’s webinar presentation, he identifies 19 lessons that he has learned over the past five years implementing Agile development projects.  Most of these projects have been very successful but some not as successful.  It is important to understand that the Agile journey is a learning process and that we cannot fail as long as we apply the lessons learned from both success and adversity.  Our hope is that by sharing these lessons you will reach success faster.  Here are the first three!

Lesson 1 – Agile is Difficult.   Well, all of you that have ventured headlong into your first few Agile projects certainly understand this to be painfully true.  You read all the best books on Agile and Scrum and thought “hey this makes sense and it is seemingly simple”.  But then the fun starts.  Customers, stakeholders and end users aren’t as involved as they should be.  Management is still trying to embrace new management principles.  The Scrum Master is attempting to break out of his or her “command and control” paradigm.  She or he  is struggling with the idea that the team must figure out how to work together as opposed to being told what and how to do things.  The first few sprints will test the organization’s commitment to this new way of doing business.  The probability of slipping back into the old ways is very high.  Stay the course!  Understand that it is a rough road at first but you must persevere by holding steadfast to the principles of Agile.  Hide nothing!  Make management aware that this will be a struggle, but the rewards are too great to fall back into the “old way” of doing things.

Lesson 2 – You Need an Evangelist. It is tempting to think that you can weather the storms of adoption alone.  But in our experience, you risk sliding down the slippery slope of adoption failure unless you have an experienced “Sherpa” to guide you.  One of the most critical success factors is to make sure you bring in a coach that can lead you through the difficult transition period that is characteristic of Agile adoption.  This individual knows the pitfalls.  They know how successful Agile can be if the right foundation is built.  They know how to stand up to Management and they know how to build teams and gain cooperation with the business and stakeholders.  Invest in an experienced, road-tested Evangelist!

Lesson 3 – Train the Business. In most organizations, Agile initiatives start with the IT group.  It is usually driven by an application development team that is self-schooling its way through Agile.  Perhaps they even send a couple of folks to get their Scrum Master certification.  But in our experience, the adoption to Agile principles is less difficult for those in IT than it is for the business and stakeholders.  That is why it is of great importance that as much, if not more, training is focused on the business community.  And the first place to start, if you are adopting Scrum, is with the Product Owner.  The Agile projects that have had the greatest levels of success are the ones that invested in Product Owner selection, training and mentoring.   In a blog article I posted in 2009 entitled Product Owners – The Guardians, I stated: “Selecting and preparing the right Product Owner that will diligently and passionately drive business value should be the number one critical success factor in making Agile-Scrum work.”

OK…so now you have the first 3 lessons, and I believe the most important ones in getting started.  Understand and accept the fact that Agile adoption is difficult, invest in a mentor and leader that has the experience, passion, integrity and emotional fortitude to keep the adoption initiative on track and invest in the selection, training and mentoring of your Product Owner.

In my next article I will cover 3 more of Jim’s Lessons Learned:

  • Determine if your project is a good candidate for Agile
  • Prepare the Product Backlog before Sprint 1
  • Build a Release Plan

Have a great week everyone.

Pete

Hello All,

I wanted to share this YouTube video with you. It is for CAI’s Automated Project Office. The video was just released. The full site is www.automatedprojectoffice.com . Let me know what you think.

Pete

Hello All,

I had the opportunity recently to present to a group of current and future leaders in my home state of Delaware.  The topic of the discussion was Building Partnerships: An Evolving Leadership Imperative and was given to the Leadership Delaware organization class of 2010.  I thought I would share the discussion with my readers.

Enjoy, and as always, I welcome your thoughts!

Pete

——————————————-

Building Partnerships: An Evolving Leadership Imperative

I am currently reading the book “All for One: 10 Strategies for Building Trusted Client Partnerships” by Andrew Sobel.  In the first Chapter of the book Mr. Sobel describes the redwood forests of northern California which provides an interesting metaphor for the topic I will be discussing here. 

You see the Redwood tree is a remarkable feat of nature.  This monster of a tree can grow up to 350 feet tall.  It is the tallest living thing on Earth.  And yet its root structures are often not more than 6 feet deep.  If you do the math that is only 1.7% root structure in comparison to the tree that is above ground.  Well I can tell you from pulling weeds in my back yard that some of those weeds probably have a 50% root-to-stem ratio as witnessed by the back strains I have experienced trying to pull them out. 

So here you have a tree with a root-to-stem (albeit a big stem) ratio of 1.7% and yet these things don’t fall over in the first windstorm.  And they stand for 500 to 1000 years.  How is this possible? 

The answer appears to lie in partnership and collaboration.  That root structure spans out some 80 feet from the base of the tree.  And when it meets up with the root structures of adjoining trees it intertwines with them creating a network of roots that is extraordinarily strong and supportive.  You see, underlying the entire Redwood forest is a fascinating display of natural order, collaboration and coexistence.

Now if you are a nature lover you understand that this is not unique.  Much of life has evolved this way.  In fact the whole of nature which is seemingly “out in the open”, “unstructured”, “unscripted” if you will, has evolved as partnerships between one living species and another.  It is the essence of what life is, is it not?

So what does this have to do with a discussion on leadership and partnership in the business world?

Well, let me first start off by telling you a bit about the world that I grew up in.  It was a world characterized by the cold war.  It was a global climate of suspicion and mistrust, closed borders and the Berlin Wall.  In business it was a world of intense corporate competitiveness, silos of capability, “not invented here” thinking, hierarchical command and control structures, low tolerance for ambiguity and uncertainty, contract-clad relationships, closed doors and proprietary information paranoia.  You were either a corporate citizen or an outsider.  If you were an outsider you were a competitor, a supplier or a customer.  Information flow and communication was obviously closest with the customer (albeit tightly controlled), only as absolutely necessary with suppliers and nonexistent with competitors.

Margaret Wheatley in her book “Leadership and the New Science: Learning about Organization from an Orderly Universe” published in 1992 described the organizations of the day in this way.

“Many of the organizations I experience are impressive fortresses.  The language of defense permeates them: in CYA memo-madness; in closely guarded personnel files; in activities defined as campaigns, skirmishes, wars, turf battles and the ubiquitous phrases of sports that describe everything in terms of offense and defense.  Some organizations defend themselves superbly even against their employees with regulations, guidelines, time clocks, and policies and procedures for every eventuality.  One organization I worked in welcomed its new employees with a list of twenty-seven offenses for which they would be summarily fired-and the assurance that they could be fired for other reasons as well.  Some organizations have rigid chains of command to keep people from talking to anyone outside their department; and in most companies, protocols define who can be consulted, advised or criticized.  We are afraid of what would happen if we let these elements of the organization recombine, reconfigure or speak truthfully to one another.  We are afraid that things will fall apart.”

I must admit that I subscribed to this mode of operation to some degree.  I suppose it made sense at the time and it was commonplace.  To be a leader in an organization when I first entered the business arena was actually not really that difficult.  You lived within the walls of a company.  The people you worked with for the most part were all within the walls of that company.  There was a hierarchical structure that was generally obeyed.  Leaders identified strategic projects and prioritized them; Managers built project plans, set up tasks and delegated responsibilities to others.  “The worker employee” basically followed instructions.  I obviously oversimplify but that was the dynamic of the relationships.

You invented and innovated within the walls of the company.  If you needed a specialty you usually hired it.  The business problems, the technologies, the processes were all advancing rapidly but were still relatively easy to understand.  At least in my field the competition was generally regionally-based and limited in number.  We all pretty much had similar ways of delivering the services we provided and since there were not a lot of competing models, value propositions or differentiators, winning typically came down to price and the strength of the relationship with the customer.  And when we did win the contracts and associated extensions, assuming you didn’t do something catastrophic, could last for years.  So I guess what I am saying is that these were the “good old days”.

Leadership back then could be equated to guarding the caches; building fortresses to keep enemies out and to instill order within the walls; keeping a watchful eye on those that would threaten our livelihood and cultures and to resist change by creating orderliness that was rigid and un-malleable.

Now fast forward…

Our world today can be summed up in two words:  Speed and Complexity.  The business organizations of today must constantly and rapidly redefine themselves against an ever changing business landscape.  The things we called value 20 or 30 years ago no longer apply.  Information rules!  Business transactions are carried out in milliseconds or even nanoseconds.  A quick search on the Google can yield hundreds or thousands of bits of knowledge in a matter of seconds.  A misguided thought or statement made late in the evening can be heard on the other side of the world and can start a viral response before we have eaten our breakfast.  Well-guarded secrets are now shared freely and in great detail on sites such as WikiLeaks.  Hackers and terrorists threaten to wage war on our personal and national wealth…security has become an elusive state of being.  Response and action are measured in a fraction of the time we used to allow.  Thanks to companies like WorldCom and Enron, there is an ever-increasing distrust in the empires of commerce and a sea of new regulations that must be addressed at every turn.  Social networking has introduced a new and evolving paradigm for human interaction.  Tom Friedman has revealed to us that the world is truly flat:  A global economy drives our social, technological and political infrastructures.  And creating value for clients is like shifting sand. 

A new model of collaboration has emerged and is changing the old command and control organizational designs.  In the world of information technology, hundreds if not thousands of visionaries, architects, designers, developers and testers all come together from around the globe to innovate new products that are created in a distributed, loosely coupled set of virtual teams under new agreements and contracts that are unlike the rigid and controlling legal mechanisms of the past.  And in many cases they are not motivated by profit and salaries, but rather through the challenge of being a part of something revolutionary, challenging, fun and inspiring. 

Open source software development is challenging the old definition of value, the hierarchical command and control structures we thought were necessary for success, the nature of team work and the traditional institutions that had a lock on the software development industry. 

Open market places and the “Long Tail” of economics as described by Chris Anderson have emerged and are changing the economics of many industries.  The traditional world of one vision, one design that we market, sell, upgrade and maintain is being played out today in an open market place characterized by the new mantra…”There’s an app for that”.

We now live in a world that is no longer characterized by single products or services delivered to individual customers but rather one of complex, integrated solutions made up of components, modules, interfaces, disparate data stores and people that must be delivered in end-to-end, integrated but loosely coupled solutions that meet the needs of many and that must grow, change and evolve with the needs of individuals, communities and businesses.  No one individual or company can serve all the needs of a market or even a single customer anymore.  The need for malleable frameworks and organizational models made up of an ever-changing set of customers, suppliers and competitors is evident.

Even the traditional employee-employer relationship has changed.  Employees, once loyal for years to the company that held their paychecks, are now more akin to free agents.  Mass layoffs, reductions in pay, elimination of retirement benefits has strained the company “lifer” paradigm and is being replaced by a more fluid workforce that seeks out the “best situation for now” as opposed to the “best situation for later.” The trust has been breached and the labor market is not governed by the laws of the collective but rather by the laws of the individual that continually seek win/win relationships in their employment situations.

Suppliers are no longer entities to simply haggle with over price or to penalize for missed expectations.  They have evolved to be contributing members in the value chain; involved deeply in customer and market strategies.  Our relationships with our suppliers is requiring a true understanding of what they value as a business and true collaboration in an open forum of customer/supplier in order to create an integrated vision of business value.

Competitors of old are now partners.  In every company/competitor situation lies an opportunity to join forces to exploit the unique capabilities that each company can bring to the table to deliver rich and sustainable solutions to the markets they serve and to enable them to enter and capture new markets.  Innovation and growth today demand that we open up dialogue, exploit emerging technologies and seek out emerging markets in what Kim and Mauborgne have called “Blue Ocean Strategies.”

In the old paradigm, partnering with customers used to mean conducting focus groups, doing customer satisfaction surveys and the like.  In today’s world, customers are called upon as true partners to define needs, submit design ideas, collaborate with design and development teams and define pricing and packaging scenarios.  We now allow and even require that our customers are active participants to shaping our products and services.

So what does this all mean for the leaders of tomorrow?

As stated before,  to be a successful leader in the world today is a lot harder than it was when I started in the business world.  It requires an entirely new mental framework, new skill sets and a required appreciation for collaborative partnerships that reinforce the notion that the whole is greater than the sum of its parts.

Marshall Goldsmith, the founding director of the Alliance for Strategic Leadership states that “the ideal leader is a person who builds internal and external partnerships.”  Marshall conducted a study of some 200 high potential leaders and his results point to the ability to foster and manage partnerships as the key differentiator of a successful leader.  His results show that the successful leader fosters both internal and external partnerships within an organization.  The internal partnerships are with direct reports, co-workers and managers.  The external partnerships are with customers, suppliers and competitors.

In Marshalls report, “Building Partnerships” he states that:

“The leader of the future will need to be skilled at managing these relationships.  In many ways, telling direct reports (who know less than I do) what to do is a lot simpler than developing relationships with partners (who know more than we do).  Working in a silo is simpler than having to build partnerships with peers.  Taking orders from managers is simpler than having to challenge the ideas that don’t meet customer needs.  Selling a product to customers is simpler than providing an integrated solution.  Getting the lowest price from suppliers is simpler than understanding their complex business needs.  Competing with competitors is simpler than having to develop complex customer-supplier-competitor relationships.  The challenge of leadership is growing.  Many traditional qualities like integrity, vision and self confidence are still needed.  But building partnerships is becoming a requirement, not an option for future leaders.”

I ran across an article on the internet that provided what I believe to be a fairly comprehensive review of the role of the leader in fostering partnerships in today’s world.  This article entitled “A Pocket guide to Building Partnerships” was published by the World Health Organization.  Although this is not a complete list of the roles and responsibilities of the future leader I think you will understand from this abridged list just how crucial the role of leadership is to building and maintaining partnerships to drive true value.  The article states that new leaders of today must:

  •  
    • Have a clear vision of the value that the partnership will deliver that is shared and clearly understood by all partners in the value chain;
    • Assess and understand the mutual needs of all partners.  What are their business drivers, what represents success and a win/win relationship to them?;
    • Welcome and ensure the free flow of information while at the same time making sure the proprietary interests of all partners are protected;
    • Define the structure and management of the partnerships to ensure that clear expectations, accountability, fairness, efficiency and effectiveness are maintained;
    • Monitor formal and informal power-bases to ensure that all parties are represented and have an equal voice;
    • Have an operating mission that will clearly define how the partnership will accomplish its goals;
    • Create, adopt and agree on a common language;
    • Understand the differences in culture between each partner in order to accommodate those differences;
    • Be a facilitator, not an authoritarian;
    • Ensure that the objectives of the partnership are achievable;
    • Make sure the priorities of the partnership are well-established;
    • Define the rules, roles, responsibilities and duties within the partnership;
    • Facilitate and drive quick decisions;
    • Enable the building of relationships across partners;
    • Ensure that the “right” skills and expertise is represented and;
    • Ensure that the partnership and subsequent solutions are fiscally sound.

Now I submit that this is a somewhat daunting list but then again, as leaders, we must rise to the occasion.  As Marshall Goldsmith has pointed out, innovation and growth today demand an integrated and intertwined network of partnerships that will form the root structure and stability to enable individuals and organizations to rise to new heights; that will enable them to become the Red Wood trees in the global forest of business and commerce.  And the current and future leaders, regardless of the industries they serve, will become the catalysts to making this happen.