Scott R. Coplan

Ministry of Good and Bad Ideas

The Problem

The U.S. Patent and Trademark Office (USPTO) is like a database of good ideas. There are many legal protections for unfair competitive advantage with patents and trademarks, but fundamentally the Office fosters innovation.
The USPTO is kinda like a Ministry of Good Ideas, ala Harry Potter. Since I prefer to see the whole picture, instantly, I transformed it into the Ministry of Good and Bad Ideas (MGBI), doubling its current capacity. With a flash of a wand, MGBI is a place where you prove a project implementation includes good and bad ideas. Once approved, the Ministry stores these ideas on a shelf for all to see whenever they want to do a new project. (By the way Sweden has a museum of product failures).
I know there’s no such thing as a MGBI, promoting success and vanquishing project mistakes. But there must be a specific way to account for good project ideas we can use while understanding bad ideas to avoid. So, what are they?

The Solution

A Project Management Office is a fine place to store good and bad project ideas. Other than that, what’s the best way to consider these project ideas? In my book The Integrator, I created DELTA, a framework that includes change management and the Agile philosophy applied to IT and Project management. A principle of this framework is each discipline offers their own approach, but they do not stand alone. Each needs integration to supplement and augment the other. In their own way, each offers an approach to encourage good ideas and discourage bad ones, but integrated they increase project success by addressing the following:

Change Management – Assesses the climate of the organization, by administering an implementation history survey, including:
    • Identifying if there is a history of enablers or barriers to implementation, like previous repeated successes or failures, clarity of project objectives, expectations concerning future initiatives, and so on
    • Finding if there is a complete picture of all initiatives and whether they are competing for the same resources and effecting the same parts of the organization
    • Determining how management controls the number of priorities and the effect of their sequencing on the organization 
    • Establishing if initiatives support the organization’s vision
    • Uncovering if lines of authority are clear and whether leadership communicates, demonstrates, and reinforces commitment and ownership to change and how it effects employees
    • Comprehending if leadership communicates by perspective-taking, or listening, understanding, and considering the other person’s point of view before speaking or acting
    • Discovering if there is a basis for managing resistance to change 
    • Noting if the organization’s participants feel involved in change and change agents have the authority to help them 
    • Concluding if the organization establishes feedback loops and measurement reporting systems, so leadership, change agents, and targets can share the same real time information about change initiatives
Agile Project Management – Prepares a Closeout Report, at project completion, to document:
  • Achievement of measurable project objectives or not and why
  • Identification of what went right and why
  • Specification of what went wrong, why, and recommendations on how to avoid repeating these mistakes
  • Acceptance of each deliverable or not and why
  • Execution according to the planned schedule or not and why
  • Performance according to the planned budget or not and why
Agile IT Management – Encourages good ideas and discourages repeated mistakes by:
  • Relying on the product owner as the primary customer representative about requirements throughout the project
  • Working with self-organizing teams, who take ownership of their work, motivating development of new ideas 
  • Conducting sprints or short work periods, including a collaborative meeting at the end of each sprint, where the product owner reviews what the team developed and provides feedback
  • Performing a retrospective, held after the sprint review, to discuss what went well during the previous sprint and what the team can improve in the next sprint
This integrated approach reveals successes and failures, as if there were an MGBI, which gives us a better understanding of how to achieve the purpose of future projects.
Recent Posts