Preventing a Meltdown in 1787 OR How Courageous Scope Management Saved your Fireworks

This is a reprint of a post I wrote in 2009

As anyone who has read Howard Zinn’s Peoples History of the United States will tell you, there’s always a different way to view our history. For example, on a recent trip to Mount Vernon, I found out that George Washington died of a disease that slowly constricted his throat until he couldn’t breathe; in effect, he strangled to death.That still gives me the chills.

Anyway – since we are celebrating our national birthday on July 4, I thought it appropriate to think about how this country almost never came into being; through my rose colored Project Management glasses.

Ok so its 1787. Lets say that George Washington is the Project Manager for the ‘Create the United States’ project.In theory, George should be happy. After all, the project:

  • Had a clear vision and deliverables (Just for fun I created a Project Charter based off the Declaration of Independence)
  • Managed to mitigate some serious risk like losing the war and getting hanged.
  • Achieved its key deliverable, free and Independent colonies with a centralized government
  • Established ongoing change management process formalized in the Congress and the Articles of Confederation

And everyone was free to pursue life, liberty and the pursuit of happiness. Right?

Wrong. The reality on the ground was:

  • The national legislature, wandered aimlessly about the country, with no permanent home.Didn’t matter, cause barely any representatives attended.
  • States were bankrupt
  • Trade was dwindling
  • New England was thinking of forming its own country
  • Revolutionary war vets were donning their old uniforms and threatening to take over the government of Massachusetts.

Clearly, something wasn’t right.The initial set of requirements for the ‘Create the United States’ project were called the Articles of Confederation. And the Articles were failing; what was built wasn’t meeting the mark.The utopia envisioned in the project charter was a distant possibility, not a daily reality.

I just finished watching Andre Augusto Choma’s most excellent presentation at the PMI EMEA conference in May of this year where he lays out the Top 10 Ways to Kill a Project.  Number 1 is to Have a Vague Scope and number 2 is to Never Revisit the Scope.

I would argue that the Declaration of Independence was fairly vague when it came to how newly Free and Independent states would relate to each other.  Of course, there was pressure to act quickly so I imagine that a modern day PMP would attempt to raise the issue at the signing, probably would have gotten shot down and therefore would add a risk to the risk register something like:

Create United States Project Risks

Structure of Government and Interrelationships Between Governments Has Not Been Determined.

Lack of Clarity Around Future State Executive Decisioning.

And in fact the Articles of Confederation tried to deal with these issues, but produced a set or rules, rather than a mechanism for creating rules.

Further, lost in the Articles was the clear vision of Life, Liberty and the Pursuit of Happiness, the protection of which is implied but not clearly spelled out in the Declaration of Independence.

Knowing this, Washington called for time out.The project scope needed to be revisited.And the whole change management board (CCB aka The Congress) had to decide and approve a change, unanimously and collaboratively. In effect, the Constitutional Convention of 1787 was a really one massive CCB in response to one massive scope change request.

Sometimes Project Managers have to force the conversation, to shed the light on a problem and keep it on until the problem is fixed. Project Managers need to have the courage to be the force for change, and sometimes, to be the whistleblower. I’ve advocated for vision keepers in another post on this blog, and I would say that George Washington’s courage and actions during 1787 is the physical manifestation and examplar of that vision.

Seriously, let’s think about the ‘what if’. What if Washington took the CYA route on this one.He would’ve sounded something like this:

“Hey, you know, I didn’t sign the Project Charter or the Requirements Document, so I’m off hook here. I’m going to catch some fish.”

'Create United States' Work Brekadown Structure - Click /tap to see larger

I digress…Here’s how the CCB changed the scope:

  • The United States would not be considered a ‘league of states’.Rather the United States would be considered a ‘Union.’
  • Power would be centralized in a strong executive, a central Supreme Court, and a centralized legislature with a permanent home.
  • The centralized power would be limited by a series of checks and balances.

In effect, the old requirements were scrapped and new set, called ‘The Constitution’, were written.The original intent about life, liberty, defense, pursuit of happiness from the Project Charter was still there. But tellingly, the most important new requirement became the first sentence of the new requirements document.

“We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.”

And the rest, as they say, is history. Thank God George Washington tenaciously mitigated for project risk. Thank God a solid CCB was in place to skillfully and honestly manage scope change requests.And Thank God for Rule of Law.

Have a great holiday.

“Create the United States’  Project Documentation

The Project Charter

My rewrite of the Project Charter

The First Requirements

CCB Meeting Minutes

The Second Requirements

Advertisements

10 Software Project Questions to Define the Real Problem

Here’s where 90% of software PMs get into trouble – they don’t understand the real problem they’re solving.

On your current project, do you know and understand the real problem you are solving? Or have you accepted the project sponsors (or clients) translation of the real problem into the technical domain?

fork-in-the-road_medium

Most clients don’t want to take the time to pay development teams to figure out the real problem. So they believe they’ve done so themselves. By the time your team shows up, assume you’re the very end recipient on a very bad game of telephone. Senior managers, executives, project sponsors—rarely translate from real problem to tech solution correctly.

For Example: An association (true story by the way) decides it needs to automate membership, because all the CEO sees is some super low membership turnaround metrics and wants to speed it up.  So said CEO hires a team to install a new CRM system.  Turns out that the development team finds out months later that many membership decisions are subjective and can’t be automated, so the CRM system gets installed as instructed by the CEO and is useless to membership.  $500K down the drain and a bad rep for the CRM company.

It’s like the beginning of the project is that all important fork in the road. Take the wrong fork and months later, there’s no recovery. It behooves you to stall for a few minutes to figure out which road to take.

Unfortunately, you won’t have a lot of time to understand the problem, and in fact, you probably won’t even get paid by the client to do so. If you can, build in a few days for problem analysis into your contracts, and get your client’s permission for unfettered access to talk to future end users. If they balk, whip out your handy dandy project failure statistics and tell them you’re trying to ensure they get on the right side of the stats.

And here’s something very telling – if they don’t want to give you access, seriously reconsider taking the project. I’ve had that mean the following:

Danger Will Rodgers! The person is building software to their own glory and you’ll be at the whim of psychopath.
Hornet’s Nest: There’s so much internal politics and complication that what you’ll build will never be useful and the client will blame you.

So here are a list of questions I’ve honed over the years to help you get to the heart of the real problem; 7 questions to ask your end users, and 3 questions to ask yourself.  On some projects, you’ll have a BA who is paid to do this.  Go with them and make sure they are asking the right questions.  Most of the right questions are listed for you below.

10 Software Project Questions to Define the Real Problem

7 Questions for your Future End Users.

1. Why does this business exist?

2. Why does your department (or organization, or unit) exist?

3. How is your department connected internally, within the business (HR, accounts payable)?

4. How is your department connected externally, outside of the business (customers, shippers)?

5. What information, goods, data comes in to your department?

6. What information, goods, data goes out of your department?

7. What’s wrong with the current process and what’s pissing people off?

Here’s the deal.  Questions 1-6 give you the language and credibility in the eyes of the enduser to ask question 7.  You can’t understand what’s wrong until you understand the process.  And what’s wrong is the reason you’re hired and the key to your glorious success.

3 Analysis Questions for you

8.  What problem am I here to fix?

9.  If I solve this problem technically,will I create problems somewhere else in this organization?

10. What are the limits of technical fix and is that ok with the client?

Here’s what I’ve found doing this analysis:

The First Solution is Never the Right Solution: The technical fix suggested by the client or project sponsor prior to my end user analysis almost never really gets at the heart of the problem.

Misunderstanding Leads to Failure: I fail if I don’t solve the real problem.

Not All Problems Have a Technical Fix – and I Need to Let My Client Know That: The technical solution almost never solves 100% of the human problem. And I let my project sponsors become aware of that well before the project begins.

Tales from Real Life: Emergent Themes in Scoping DoD Office Automation Projects

My team is starting to get a lot more work. As a group dedicated to SDLC discipline we have bought in good process that makes our clients feel secure and we are proving that process works through encouraging consensus, through not moving forward until we have clear requirements, through honestly and actively managing risks and ensuring quality through system architecture and testing, (I know…yadda yadda yadda).

So ..last week we got a new client. I found out about the client on Tuesday via phone directive from a senior-control-the-purse-strings exec. It’s all good because the work falls under our program mission. So Wednesday, we met for the first time with the client. Thursday I wrote up the charter and held a scope meeting teleconference with the POCs. By Thursday evening the draft charter was done and I knew:

  • What were the key points of process pain
  • What the overall doctrine and mission was driving the emergent need for a change
  • What the application was supposed to do
  • Who the stakeholders were both internally, and externally and
  • High level risks
  • I have completed my Project Chater Muahhhahahhhahahahaa!

    I have completed my Project Chater Muahhhahahhhahahahaa!

    And I stood back from my creation, the way a mad scientist steps back from the machine he has worked on for days, and realized…..dang! That was quick!

    Talking to the Senior BA on the team we both realized that perhaps we had hit on a formula. We’ve been in the DoD environment for almost a year and I know that doesn’t make us pros in Dod IT. But what we do bring is experience in corporate America CMMI level 3 and 4 IT shops. And that experience, and subsequent application of laser focused methodology we absorbed in those environments, means that we have established repeatable processes from which we are starting to see patterns. For initial project scoping, the patterns are lending themselves to some potential themes which I thought I would share with you.

    DoD IT Theme 1: The Two Reasons for Everything Office automation applications are meant to do one of two things:

  • Get information faster
  • Reduce the time it takes to get things done
  • To be successful, we focus on finding out what that needed information is, who owns it and how we’re going to get it and manage it. And if the app is envisioned to reduce time, then we find out what bottlenecks exist and how the app is supposed to fix the bottlenecks. The two reasons imply that there is pain the process somewhere, and if there is no pain, then there may not be enough support for the app if for example, another point of pain becomes a higher priority.

    DoD IT Theme 2: The Doctrine is the Key Every organization in the DoD has an overriding doctrine that determines the mission. You need to understand the doctrine to understand how the organization you’re working for fits into the whole structure. And you need to understand the fit to know:

  • The true reason for the existence of group you serve and what they are supposed to accomplish
  • Additional stakeholders you need to include in your project planning
  • Additional data silos you may need to peek into or get data from
  • DoD IT Theme 3: Vetting Takes Time Finally, there is the stakeholder formula – how long it’s going to take to get everybody to agree. Basically, the Pentagon is a huge vetting organization. Anything you do will have to go though a lot of people for approval. The more external organizations you have to connect to, the more risk is automatically assumed and the longer the application is going to take to get done. So I think it goes like this; for every additional outside stakeholder group you have to connect with, add planning time. Your first group adds on at least one month. Additional groups add on additional 2 weeks.

    # of Groups and approximate Vetting Times

  • 1 group = 1 month
  • 2 groups = 1.5 months
  • 3 groups = 2 months
  • 4 groups 2.5 month
  • 5 groups 3 month
  • 6 groups 3.5 months
  • Making it usable Here’s how these three themes worked for me:

  • Theme 1: On this project, during initial scoping, I probed to see if either the new application is envisioned to get information faster and/or reduce the time it takes to get things done. This line of inquiry was fruitful in getting to the true need, which is what the business case hinges on. And the fixing of this problem ‘thing’ will bring capability to the organization that didn’t exist before.
  • Theme 2: I asked for the doctrine supporting the mission of the organization. I then found the doctrine online, studied it and got up to speed fairly quickly on additional stakeholders and silos. This got added to the Charter as the overriding guidance to follow and was confirmed later by the POCs.
  • Theme 3: This application will take a considerable amount of information consolidation with about 3 different organizations. This has become a risk to mitigate that we’ll discuss in our risk mitigation session next week.
  • What could have happened Had I not been aware of these themes here’s what would have happened:

  • Missing Theme 1: I would not have realized that we were replacing a manual process that caused a lot of misaligned information. This fact didn’t come out until I asked specifically about the reduction of time question. And the implication is that we would not have studied this existing process to ensure we ported it over correctly to the app. It would have been lost until the last minute when someone would have said ‘hey – what about Form A, B and C – we need to automate those too.’
  • Missing Theme 2: I would have a conception of the envisioned application that was wrong. By studying the doctrine I realized that there were two aspects of the mission that needed to be addressed to be successful, not one. We would have built for one thing only, and the other would rear its head probably super close to deployment, well after the app was built.
  • Missing Theme 3: I would have built a schedule around just this organization only to have it skewered by outside groups who would get miffed by not being included in the planning.
  • You know what they say, an Ounce of Prevention is worth a Pound of cure.

    45 IT Projects put on hold at Veterans Administration (VA)

    Honey stop the car! Is that PM governance and portfolio decisions based on project performance happening in the …Federal Government?

    I’m almost at a loss for words.

    The New CIO at the VA, Roger Baker, is now holding IT projects to milestones and stopping projects when they don’t make the milestones.  He claimed he would do it when he started in June.

    The Eliott Ness of Project Management?

    The Eliott Ness of Project Management?

    Holding true to his word he’s put 45 IT projects on hold This has implications beyond just the VA, because I believe other Gov OCIOs will follow suit.

    My initial thoughts are:

  • I’m glad to see project assessments that lead to definitive and clear actions to get projects back on track.
  • I think this will reverberate in other agencies.
  • The time out will be crucial to see where the project failures are occuring.
  • From initial articles it seems that Decision Making Failures may be a common cause of failure.   From my own observations I also think that this action will also uncover Project Discipline failures within contracting firms.
  • This action will be successful to the extent that the VA can put processes in place to mitigate for these failures.  In other words, stopping and starting is not good enough.  They have to Stop – FIX- Start and of course….measure.
  • Visualization  is the new black.  This tool http://it.usaspending.gov/ helped make the decision.
  • This is starting to look like Vivek Kundra’s vision writ real to take a Wall Street mentality to Projects as in ‘buy, hold, sell’.

    “First, apply the efficiency of the stock market to IT governance. In an environment of shrinking budgets and growing citizen expectations of government, evaluating the performance and promise of IT projects continuously and accurately is critical. With the Wall Street model, we can make fast and sound decisions to “buy,” “hold” or “sell” an IT project — that is, invest more financial resources or change management to improve performance, maintain the current resource level or cancel a failing initiative”

    Read more on the ExecutiveBiz blog

    Looking forward to your comments.

    Making Theory Usable: Project Scope Tips to Mitigate for Definition Failures

    The Truth is Out There

    No silly, not Area 51, the truth about how to keep your project from failing is documented just about everywhere.

    I’ve Been reading a lot about this lately and I see so many commonalities and connections in theory and metrics on project failure, that I’m compelled to say that, should you want to, you’d be able to connect the dots quite easily. The top reasons for IT project failure are well summed by the National Audit Office(NAO) of the UK, who incidentally is currently in charge of audit on the UK’s attempt to convert all their health systems into one large integrated database, arguably one of the largest IT projects ever attempted. Reading about it kind of makes you scared to start IT health projects here.

    Back to project failure, the National Audit Office came up with 5 risk factors as indices of potential project failure.And a few fellows at the University College of Londonmeasured their project success rates against these 5 risk factors and found good correlations. They describe these keys as follows:

      Design and definition failures – the required outputs are not described with sufficient clarity so the end goal is not achievable,
      Decision making failures – the project fails due to lack of a single responsible owner who is able to make decisions about the project,
      Project discipline failures – project documentation replaces project management with poor arrangements to identify and manage risks properly,
      Supplier management failures – the project fails due to lack of understanding between the supplier and the customer,
      People failure – occurs when the project delivers as specified, but the project does not fit the business or clinical requirement.

    I would change People Failure to ‘Intent Failure’.Meaning that the intent of the project was not achieved even though the project was delivered. KPMG calls this ‘unrealized benefits.’

    And I would like to add a sixth factor:

    · Quality Assurance failures – Failure to thoroughly test for quality, stress, and load.

    This is sounding similar to Andre Choma’s recent presentation at the EMEA PMI Conference on the Top 10 ways to Sink a Project.

    Making theory usable:

    So with all these resources available, I think the prevalence of IT Project Failure means that these ideas are not efficiently translating into practical and usable tips for the average IT Project Manager. With that thought in mind, I’ve decided to start a blog series focusing on one risk factor per blog. The idea is to provide tips and examples from real life of how to mitigate for the risk on your projects.

    Today’s topic: Design and definition failures

    Tip 1: Start with a super clear Project Charter. Clarity in a Project Charter is so very important. I’ve always made sure that my Project Charters included the following:

    A description of the problem to be solved. The Charter should fully describe the problem to be solved, in detail. I often find this the easiest piece to write because its basically the ‘complaint’ section of the narrative and I’m good at complaining. Read my post about how complaining can help you find risks, because complaint can also help you find the business problem.

    Example: (Note – the example language is taken from a real-life project)

    The CEO is the command authority for the ABC Corporation. On a daily basis, The CEO will receive highly critical and important communications from over 10 sub organizations. The CEOs quick action and response is usually required on various items. The primary method of communication used by sub organization staff is email and includes PowerPoint decks, reports, charts, maps, and project updates. The CEO’s time spent sorting through email produces the following outcomes:

    · Reduces the amount of time to make key strategic decisions

    · Carries inherent risk that important information may be missed in voluminous email traffic

    A 2 or 3 sentence scope. Even on the largest projects, you should be able to state what the end goal is very succinctly. I’ve found that when I could not do this, my scope was either too large or too fuzzy. So my practice is to force myself to say the purpose of the project in a 15 second elevator pitch. I’m currently reading the Dod’s Capabilities Based Assessment User’s Guide which I will blog out a bit later. But what’s fascinating for me is that the DoD has created a business problem definition process which forces the DoD to describe the business problem in terms of a capabilities required, rather than in terms of the ‘thing’ that is required. The Guide says “…replace statements such as “we need a more advanced fighter,” with, “we need the capability to defeat enemy air defenses.”” (page 5).

    Example:

    The CEO has envisioned a central executive level dashboard of information that will serve a primary hub of communication and one stop shop where the CEO can quickly and immediately discern and respond to important information.

    Note that this scope is written in terms of capabilities ‘primary hub of communication’ and does not specify the product to be used. This scope document could just as easily have said, “The CEO needs a Sharepoint dashboard.”Stating the technical solution in the scope document can mean a loss of the business requirement. I believe the DoD discovered this issue which is why they focus on capabilities, rather than requirements.

    A link to an existing business objective. Link your project to company strategy. If you can’t link to any of the existing strategies, that’s your clue that you may encounter buy-in risks or lack of executive support. This is what a friend of mine calls the ‘Give a S***’ or ‘GOS’ factor. If you can’t explain why an executive should GOS about your project, you need to really re-think the necessity of the project. At a minimum, you should raise the issue during scoping with the project sponsors and if they push back, make sure you log the risk in your risk register.

    Example:

    This project is linked to the CEO’s direction that ABC organization create and manage a more efficient, organized and productive way to receive critical information and disseminate key decisions quickly.

    Measurable success Criteria. Begin with the end in mind. How will you measure that you’ve project is successful? If you have a clear business problem, this should be fairly easy to do.

    Example:

    The following criteria will briefly describe the measurements of item completeness for the successful implementation of the CEO Dashboard application:

    1. Proven usage and adoption by the ABC organization over a specified period of time. Metrics on usages should be gathered from all levels including Sub Organization Heads.

    2. A Six Sigma analysis of the key indicators of efficiency gains over time.

    3. A repeatable content management process that includes continual updates to the application via controlled change management and code releases.

    Keep it Short: The Project Charter is not the project management plan. It should be brief and to the point so that it can be vetted through executive levels quickly. I know some may take issue with this, but I have been able to build enterprise wide web applications off of charters less than 10 pages long.

    Signatures by all parties involved. You’d be surprised how much your scope will change when you walk it around to vet it through your organization. This is what should happen however. Your scope will change because you’ll be informed of those things that may already be able to solve the problem and you’ll realize unmet needs that people want addressed. Honestly, the Project Charter process and getting to agreement should be a fairly lengthy process and there should be plenty of re-writes due to vetting. If not, you will probably be forced to re-write your scope later, in the form of scope creep or requirements change.

    Tip2: Don’t re-write the wheel. There are plenty of places to get good Project Charter templates:

    Tip 3: Don’t underestimate the visual

    If you’re like me, you’ve been raised to read and understand, not viewand understand.  In grad school, I read lots and lots of books, with no pictures, some with just a few graphs. So relying heavily on pictorial representations of anything feels like fluff to me.    But this is a new world, where executives use pictorial dashboards, like the Feds new IT Dashboard, and where inches and placement on 15 inch screens can influence a company’s bottom line.

    In the past, application requirements consisted primarily of application functionality and data requirements.  But now in this web based age where 95% of applications have a web component, usability requirements, including screen placements, application navigation and user task requirements can make or break an application.   In other words, you may have built the workflow correctly but if the sponsors don’t like what they see, they will push back.

    Worse case scenario; if you haven’t vetted a look and feel with your sponsors before you build, you exponentially increase your risk of re-work as they most likely will not accept your design.   Re-work then pushes back project schedules and increases cost.

    To avoid this scenario, employ best practices in usability and web prototyping before you begin your project.  Usability.gov provides a wealth of information including requirements analysis tools, design tips and federal government compliance information for web design.    I am currently modifying my project plans to incorporate design assumptions, and to add milestones for look and feel approval to schedules.

    The most important thing to remember here is –  get design approval before you build.

    The Milky Gold Dilemma: The PMPs Pink Elephant in the Room

    The average PMP is quite motivated and happy when they pass the exam. They are uplifted by what they’ve learned and therefore, consider it their responsibility to provide honesty and integrity on projects, and to work to the best of their ability to deliver projects under budget, on time and within scope.

    Today I just want to talk about an issue that I hear about over and over again with my fellow PMP friends. It’s a sort of pink elephant in the room type of thing that crops up in sidebar conversations, or over lunch. I call it the Milky Gold Dilemma. It occurs in small and large companies and in all industries.

    The reality is that the motivated PMP will be confronted with the motivations of those responsible for keeping their job intact. In other words, the PMP has a good job, they like their job. But the dilemma is that there are forces within that job that want to maintain a steady chug chug chug of project mediocrity to keep the money flowing. The PMP is conflicted because while they’ve signed the code of conduct, and are motivated by project excellence, they are also motivated to keep paying their mortgage.

    Ok – so a little reality check. Do the following scenarios sound familiar?

    Scenario A:

    A PMP works for a small software company. The company has sold vaporware to a client and it’s looking like that vaporware will not be built as sold. Since the sale, the developers have implemented a version of the sold vaporware, that doesn’t really work. The company has charged $200.00/hour to the client for the production of the not-really-close-enough-to-what-was-sold solution.

    Does the PMP:

  • Be honest with the client that the software is different from what they purchased and insist that the developers build what was truly sold to the client. (this is the get fired answer)
  • Keep plugging and don’t say a thing to the client. The project is still under budget and on time. (this is the keep the job answer)
  • Scenario B:

    A PMP works for a one of the Beltway Bandits on a large DoD Contract. The project is humming along nicely when the PMP is approached by his upper management to suggest scope adjustments to generate new business.

    Does the PMP:

  • Refuse and say to their management ‘I signed a code of conduct and what you are suggesting will not benefit the client’. (this is the get fired answer)
  • Appease their management, add a bit more to the scope, but push the project team like heck and to deliver the project on time and under budget so no one really notices. (this is the keep the job answer)
  • I’m being a bit simplistic admittedly and I could think of many different realistic ways to approach these scenarios. But that’s not really my point. My point is…this dilemma exists and as PMPs we’ve got to develop ways using our tools to mitigate for it. It’s the Milky Gold Dilemma. Milk, as in keep the milk flowing. Gold, as in the push to subtly goldplate.  This dilemma is unique to PMPs specifically because we have signed the code of conduct which says: “3.3.2 We do not exercise the power of our expertise or position to influence the decisions or actions of others in order to benefit personally at their expense.” Problem is, whether it’s overt or subtle, a lot of times, milky goldplating is exactly what we are being asked to do by the people who hold sway over our paychecks.

    Preventing a meltdown in 1787 OR I see PM everywhere

    As anyone whose read Howard Zinn’s Peoples History of the United States will tell you, there’s always a different way to view our history. For example, on a recent trip to Mount Vernon, I found out that George Washington died of a disease that slowly constricted his throat until he couldn’t breathe; in effect, he strangled to death.That still gives me the chills.

    Anyway – since we are celebrating our national birthday on July 4, I thought it appropriate to think about how this country almost never came into being; through my rose colored Project Management glasses.

    aka George Washington

    Project Manager Extraordinare

    Ok so its 1787. Lets say that George Washington is the Project Manager for the ‘Create the United States’ project.In theory, George should be happy. After all, the project:

    • Had a clear vision and deliverables (Just for fun I created a Project Charter based off the Declaration of Independence)
    • Managed to mitigate some serious risk like losing the war and getting hanged.
    • Achieved its key deliverable, free and Independent colonies with a centralized government
    • Established ongoing change management process formalized in the Congress and the Articles of Confederation

    And everyone was free to pursue life, liberty and the pursuit of happiness. Right?

    Wrong. The reality on the ground was:

    • The national legislature, wandered aimlessly about the country, with no permanent home.Didn’t matter, cause barely any representatives attended.
    • States were bankrupt
    • Trade was dwindling
    • New England was thinking of forming its own country
    • Revolutionary war vets were donning their old uniforms and threatening to take over the government of Massachusetts.

    Clearly, something wasn’t right.The initial set of requirements for the ‘Create the United States’ project were called the Articles of Confederation. And the Articles were failing; what was built wasn’t meeting the mark.The utopia envisioned in the project charter was a distant possibility, not a daily reality.

    I just finished watching Andre Augusto Choma’s most excellent presentation at the PMI EMEA conference in May of this year where he lays out the Top 10 Ways to Kill a Project.  Number 1 is to Have a Vague Scope and number 2 is to Never Revisit the Scope.

    I would argue that the Declaration of Independence was fairly vague when it came to how newly Free and Independent states would relate to each other.  Of course, there was pressure to act quickly so I imagine that a modern day PMP would attempt to raise the issue at the signing, probably would have gotten shot down and therefore would add a risk to the risk register something like:

    Create United States Project Risks

    Structure of Government and Interrelationships Between Governments Has Not Been Determined.

    Lack of Clarity Around Future State Executive Decisioning.

    And in fact the Articles of Confederation tried to deal with these issues, but produced a set or rules, rather than a mechanism for creating rules.

    Further, lost in the Articles was the clear vision of Life, Liberty and the Pursuit of Happiness, the protection of which is implied but not clearly spelled out in the Declaration of Independence.

    Knowing this, Washington called for time out.The project scope needed to be revisited.And the whole change management board (CCB aka The Congress) had to decide and approve a change, unanimously and collaboratively. In effect, the Constitutional Convention of 1787 was a really one massive CCB in response to one massive scope change request.

    Sometimes Project Managers have to force the conversation, to shed the light on a problem and keep it on until the problem is fixed. Project Managers need to have the courage to be the force for change, and sometimes, to be the whistleblower. I’ve advocated for vision keepers in another post on this blog, and I would say that George Washington’s courage and actions during 1787 is the physical manifestation and examplar of that vision.

    Seriously, let’s think about the ‘what if’. What if Washington took the CYA route on this one.He would’ve sounded something like this:

    “Hey, you know, I didn’t sign the Project Charter or the Requirements Document, so I’m off hook here. I’m going to catch some fish.”

    I digress…Here’s how the CCB changed the scope:

    • The United States would not be considered a ‘league of states’.Rather the United States would be considered a ‘Union.’
    • Power would be centralized in a strong executive, a central Supreme Court, and a centralized legislature with a permanent home.
    • The centralized power would be limited by a series of checks and balances.

    In effect, the old requirements were scrapped and new set, called ‘The Constitution’, were written.The original intent about life, liberty, defense, pursuit of happiness from the Project Charter was still there. But tellingly, the most important new requirement became the first sentence of the new requirements document.

    “We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.”

    And the rest, as they say, is history. Thank God George Washington tenaciously mitigated for project risk. Thank God a solid CCB was in place to skillfully and honestly manage scope change requests.And Thank God for Rule of Law.

    Have a great holiday.

    “Create the United States’  Project Documentation

    The Project Charter

    My rewrite of the Project Charter

    The First Requirements

    CCB Meeting Minutes

    The Second Requirements

    usprojectwbs

    Create United States Work Breakdown Structure - Click/Tap to see larger