Use Project as a Verb

Shift your mindset about projects from noun to verb. Projects propel your organization from its current state to a future state of compelling business benefits.

Understand Project Anatomy

Projects are about effectively managing:

• ●
  Scarce organization resources
• ●
  Commitments
  
• ●
  Expectations
  
• ●
  Cross-functional relationships
  
• ●
  Risks, issues, and decisions
  

Most projects fail as a result of sociological issues, not technology.

Consider Project Constraints

Traditional project thinking addresses three constraints:

• ●
  Cost
• ●
  Time 
• ●
  Scope

Time can't be replenished. Manage time first and aggressively; the other two will work out just fine.

Engage with Technology

Business teams must stay engaged throughout the project, not just the initial planning and requirements activities.

Design, development, testing, and deployment are critical business engagement cycles to increase outcome quality.

Undertake as Sociological Endeavor

Projects are more a sociological process than a technical one.

Most projects fail because of people (used collectively in this context to mean teams, constituents, leaders, organization, and culture) and their inability to influence the System they're working within, not technology.

Minimize Transitions

Projects have too many transitions that create knowledge "traps."

• ●
  Large projects may have up to 35 transitions between teams, and roles, e.g., generalist and specialist.

Transitions cause knowledge to be:

• ●
  Obfuscated
• ●
  Lost in translation
• ●
  Not shared

Minimize the number of  transitions by:

• ●
  Getting the right resources engaged early.
• ●
  Minimizing the number of specialist roles by encouraging more versatile generalists.
• ●
  Ensuring resources remain consistent during project work by reducing turnover.
• ●
  Using knowledge transfer and management deliverables to support transitions.
  

Choose Right Approach

The approach selected for your project should mirror the known facts of your problem domain understanding.

• ●
  A higher degree of facts and fewer assumptions support a more significant resource commitment, e.g., approve a new capability or major enhancement project using one or two resource commitment approval gates.
• ●
  Likewise, fewer facts and more assumptions support a smaller resource commitment, e.g., approve a feasibility or discovery project to increase knowledge and surface facts and understanding before committing to more significant resource commitments.

Reduce Project Proliferation

Many organizations approve more projects than leadership can effectively and efficiently manage.

• ●
  Leadership bandwidth is at a premium.
• ●
  Focus leadership and teams on the most compelling and impactful projects using discipline and assessment rigor during project filtering and approval processes.

Know Time-tested Symptoms of Failure

Project fiascos have been reported, studied, researched, and analyzed for decades.

Failed and troubled projects continue to occur at alarming rates despite well-documented, consistent reasons for failure.

• ●
  Most reasons given are symptoms, not root causes.
• ●
  Some studies report that only 30% of projects are successful.
• ●
  Different definitions of success, failure, and trouble may distort the statistics and trends reported.
• ●
  Nonetheless, there is broad agreement across top-tier research and consulting firms that project failure and trouble are unacceptable.
  

Organizations keep repeating the same thinking, organizing, behavior, and actions that trigger failure and trouble.

As Martin Cobb, former Treasury Board of Canada Secretariat, said:

"We know why projects fail, we know how to prevent their failure -- so why do they still fail?"

Develop Insight to Failure -- 12 Failure Findings from Project Autopsies

Pursuing aggressive goals, leading-edge change, and differentiated innovation may occasionally fail. That failure is good as long as lessons learned benefit future initiatives.

Most failure is bad, enabled by:

• ●
  Losing touch with reality.
• ●
  Poor problem domain knowledge.
• ●
  Large and convoluted scopes of work.
• ●
  Poor execution and team synchronization.
  
• ●
  Team dysfunction.
  
• ●
  Absence of transparent and accountable organization.
  

No organization is immune from failure. Public, private, large, and small organizations have experienced project failures, some well-documented by the news media.

Collectively, the annual global cost of project failures exceeds $1 trillion. Some analysts estimate the cost of project failure could be as high as $6 trillion when indirect costs, such as staff turnover, health, new learning curves, and opportunity costs, are added.

Avoid 7 Common Mistakes

Projects fail to deliver expected outcomes for a variety of reasons.

1. Inadequate due diligence
2. Vague project roles and accountability
   
3. Poor communication
   
4. Factless plans
   
5. Overly focusing on scope versus outcomes
   
6. Poor behavior and performance that go unchecked
   
7. Losing sight of reality
   

Perhaps the biggest reason is not dealing with or facing reality. Not facing and resolving "unpleasant realities" promptly is the downfall of many project teams.

Find the Elusive Silver Bullet

Unfortunately, there aren't any easy fixes or silver bullets.

Project failures are more complex and deep-rooted than industry pundits proclaim.

• ●
  Findings such as lack of user involvement and executive support, poor definition of requirements, etc., fall short and shallow.
• ●
  Why would executives authorize millions of dollars for projects and not support their success? It seems to be at odds with rational thought.

Catastrophic failures are usually enabled by more than problem, action, behavior, event, or circumstance, regardless of industry and product.

Stuck in Conventional Thinking

Over the past several decades, industries have invested in software development life cycles, professional certifications, management consultants, and undergraduate and graduate education programs.

Those investments have had a nominal impact on increasing project success rates and delivering business outcomes cost-efficiently.

Disregard Relationship Gaps

Historically, the relationship between business and IT teams in many organizations has been tenuous.

Today, many business professionals and teams hesitate to engage their IT teams in business initiatives.

Nurturing relationships between those teams is a critical behavior promoted by Capability Thinking® to increase the performance and value of technology investments.

Lack of Discipline in Thinking, Organizing, Behavior, and Action

Poor discipline practices in many organizations and teams may be the most significant barrier to realizing consistent project success.

Here are just a few examples.

• ●
  Unclear organization and roles
• ●
  Fuzzy visions and outcomes
  
• ●
  Dependence on intermediaries
  
• ●
  Poor role casting
  
• ●
  Abdication of responsibility
  
• ●
  Allowing accounting policies to circumvent reality
  
• ●
  Succumbing to institutional imperatives
  
• ●
  Loss aversion
  

Influence Institutional Dynamics

The real reasons many projects fail may be related to what Warren Buffett and Charlie Munger call the institutional imperative.

Employ Critical Project Processes

Here are some examples of practices that promote project success:

• ●
  Thoroughly understand problem/opportunity space
• ●
  Specify clear project roles and accountabilities
  
• ●
  Promote crisp, transparent communications
  
• ●
  Develop a fact-based plan of action
  

Use these Ingredients for Success

Employ 12 proven practices on your projects:

• ●
  Establish business sponsorship and ownership
• ●
  Define a clear business solution
• ●
  Create a concise business case
• ●
  Establish a "no blame" culture
  
• ●
  Create fact-based plans
  
• ●
  Establish the proper organization and cast the right people in roles
  
• ●
  Follow a straightforward process for monitoring and synchronizing ongoing work
  
• ●
  Leverage your organization's technology standards and assets
  
• ●
  Choose the right person to be the project manager
  
• ●
  Quantify your project plan and progress
  
• ●
  Use proven Decide, Design, Develop, and Deploy methods
  
• ●
  Design your project plan to deliver more frequent, smaller releases versus one mega-release
  

Shift your Thinking -- Drive Pragmatic Behavior

Transition from traditional project thinking to creative and pragmatic actions that are:

• ●
  Simple to implement.
• ●
  Based on business sense and principles.
• ●
  Inexpensive.

Examples include:

• ●
  Shift from larger to smaller projects using more releases.
• ●
  Move slices of critical project activity, such as design and testing, earlier in the project process.
• ●
  Use images and diagrams to communicate concepts and solutions to supplement text.
• ●
  Conduct before-action dialogues early and at critical milestones to avoid relearning lessons and creating rework.
  

Make a Difference

Strong business engagement and ownership are often the difference between project success and failure.

Building a House

Contrary to popular thought, there are many differences between building a house and developing a software application.

Physical and Visual

Building a home is a much more physical and visual process than building an application.

• ●
  Human senses (touch, sight, hearing, smell, and taste) are invaluable in guiding and completing the home-building process.
• ●
  Application building only leverages a subset of those senses. Humans accustomed to using all their senses to carry out their daily lives are somewhat a “fish out of water” when engaged in software-building activities.
• ●
  Capabilities need to leverage the use of human senses for software-building methods to be successful.

Maturity

The process, experience, and standards of building “dwellings” are much more mature than building applications. That results in repeatability, predictability, and success rates not found in application building.

• ●
  “Dwelling” construction has been learned, refined, and passed down over 400 generations. Application software construction has been passed down slightly over two generations. Note: 30 years is used to represent one generation.
  

Competency

Another key difference is the competency and skill development approach used for building houses versus applications.

• ●
  Building construction workers learn their trades by attending technical schools and hands-on apprenticeships, which represent on-the-job learning through practice and repeatability and expert mentorship and coaching.
• ●
  Organizations remain challenged to provide the best on-the-job learning, skill, and competency development, which may be the more critical aspect of becoming an experienced and expert technology practitioner.
• ●
  Practice and repeatability, combined with mentoring and coaching, produce experts--something many organizations struggle with.
  

Methods and Standards

One more area of difference is in methods and standards. Building construction methods and standards are much more mature and consistently applied than in software building.

BOM Complexity

Another takeaway is that the bill of materials (BOM) used to build application software is more voluminous than the BOM used for home construction.

Pre-built Components

Another takeaway is home building leverages pre-built components and solutions, whereas many software initiatives opt to develop everything from scratch, including knowledge.

Aviation System -- Managing Complexity

The aviation delivery system is more complex than technology project delivery. Yet, it's far less failure-prone than technology projects.

The aviation industry has significantly reduced its failure rates since 1959.

Technology project failure rates have remained generally the same since the early 1990s.

Perspective

Aviation safety impacts human life. Most technology projects also impact humans, though many not from a life-threatening perspective. So the aviation industry must engage in stringent and expensive risk mitigation, investigation, and learning.

Franchising

The organization and roles between corporate staff and line business teams are similar to franchisor and franchisee.

Franchising is a mechanism to rapidly scale a concept, such as product, retail, service, or other.

Attributes of franchising include:

• ●
  Simplicity -- the product, retail, or service concept is simple both from a delivery perspective and consumer understanding.
• ●
  Standardization -- In other words, the concept is cookie cutter. It can be relocated and replicated repeatedly, using the same standards, supply chain, and support infrastructure.
• ●
  Localization -- Local ownership and locations engage local constituents and customers.
• ●
  Corporate -- A corporate franchisor provides the methods, systems, procedures, supplies, and other support that a franchisee needs to succeed.
  

Projects are like a franchising concept within an organization.

• ●
  The franchisor represents one or more corporate staff, e.g., finance, IT, etc. They often engage in projects as corporate governance.
• ●
  The franchisee is the project, sponsored by one or more local departments.
• ●
  The franchisor invests in standard tools, software, technology, and delivery methods that franchisees can leverage.
• ●
  The franchisor also provides capital and operating expenses, through approved authorizations, to the franchisees.
  
• ●
  Often, the franchisees are people that corporate governance members don't personally know. The only form of credibility that most franchisees possess is that they successfully passed the scrutiny of HR, Procurement (for contractors), and hiring managers to be employed or retained by the franchisor's organization.
  

Top Ten Reasons why Franchises Fail

Here are the top reasons why franchises fail (sources: allBusiness; Franchise Advisory Centre).

1. Lack of Business Skills
2. Underestimating the Commitment
3. Inexperienced or Incompetent Staff
4. Wrong Location
   
5. Unaffordable Rent
   
6. Insufficient Working Capital
   
7. The Decision Is Emotional, Not Pragmatic
   
8. Inability to Compete with Nonfranchise Competitors
   
9. Lack of Franchisor, aka Corporate, Support
   
10. The Franchise System Is Flawed
    

Do any of those sound familiar?

Team Sport -- Golf

Most of us think of golf as an individual sport. But it's also a team sport.

Many American players have historically emphasized individual aspects more than the team. I don't blame them. They earn their livelihood in the sport as an individual, not team athletes.

The most talented, modern-day American players have been challenged to engage in the sport as team players.

European players have shown more adeptness and camaraderie at team play than their American counterparts. European teams have been regularly winning Ryder Cups against USA teams, even though USA players are higher ranked and generally recognized as better individual golfers.

Recent U.S. teams of new and younger players are shifting the trend by winning. Are Millennials and Gen Zers more adept at being team players? 

Takeaways

• Individual talent matters in team endeavors, but it isn't always the key determinant in winning.
• Many projects engage top individual talent but fall short in achieving desired outcomes.
• The ability for talented individuals to learn and adapt to be capable team players shouldn't be a given on any project. Prepare and reward people for winning as a team.

Produce Great Software

Don't forget that application projects must produce great software to deliver differentiating and impactful business outcomes.

Understand SDLCs Conceptually

Conceptually, software development life cycles have four cycles of work:

1. Decide
2. Design
3. Develop
4. Deploy

The difference between structured, aka waterfall, and agile is how those cycles are organized, sequenced, executed, and staffed.

Understand Structured Approach

Organizations and projects that value predictability and risk mitigation use structured approaches.

Understand Agile Approach

Organizations and projects that value responding to change use agile approaches.

Choose Structured or Agile -- What's Best?

Use the following dimensions when deciding between structured and agile approaches:

• ●
  Complexity
• ●
  Criticality
  
• ●
  Culture
  
• ●
  Change
  
• ●
  Competency
  

Know Three "Cs" of SDLCs

There's more to a life cycle than just the four work cycles:

• ●
  Cycles represent major milestones -- Decide, Design, Develop, and Deploy
• ●
  Channels represent the type of work, such as Business Process/Application, Organization, and Technical
  
• ●
  Control represents the project management methods. Projects often spin out of control when absent sound management practices
  

Relate to Analogy -- Structured SDLC

Structured software development life cycles are like trains:

• ●
  Real workhorses -- carry a lot of people, baggage, and freight, aka scope
• ●
  The terrain/scenery slowly changes
  
• ●
  The larger they are, the slower they move
  
• ●
  The tracks have many curves and twists that require deceleration
  
• ●
  Switching tracks can be tricky and consumes time
  
• ●
  Traffic control is critical
  
• ●
  The journey takes longer, but it eventually gets you to your destination
  

View Agile SDLC

Project movement is constant, iterative, and fast-paced using agile methods.

Improvisation and pivots are critical competencies for success.

Relate to Analogy -- Agile

Agile frameworks are similar to an aircraft powered by a jet engine:

• ●
  They're fast
• ●
  They accommodate varying passenger and freight loads without sacrificing speed and efficiency
  
• ●
  Incremental delivery is constant, with each increment represented by an intake blade on a jet engine that's constantly spinning to achieve speed and outcomes
  

Relate Capability Thinking® and SDLCs

Capability Thinking promotes new thinking, organizing, behavior, and action paradigms integrating structured and agile frameworks/methods to create agile business capabilities.

Critical Takeaways About Projects

Reduce the risks associated with project work by educating yourself and your team on basic project fundamentals.