A comprehensive guide to translating Vision and Mission into Products & Services — through six execution phases, four cross-functional pillars, and two continuous feedback loops
Executive Summary
The Peak Performance Framework (PPF®) is a structured business alignment methodology that cascades enterprise strategy into operational execution across every business unit. It is not a planning exercise — it is an operating model that ensures every initiative, investment, and capability decision traces back to stated Vision and Mission.
The framework solves one of the most persistent failures in organizational management: the gap between what leadership decides and what the organization actually delivers.
Core Flow:
Vision + Mission → Business Strategy → 4 Pillars → Opportunity Roadmap → Pipeline → Products & Services
Two feedback loops ensure alignment:
Business Value Assessment — Are we doing the right things?
Continuous Process Improvement — Are we doing things right?
The five elements of an actionable strategy
The Five Element Strategy In a recent conversation, I was asked to propose a simple framework for designing a clear, effective and actionable strategy that can be adopted and embraced by the leadership and well as rank and file of an organization! In future articles, I will discuss each of these 5 elements in details. For example, we will discuss how to set your organization’s goals, define the pillars, etc.. 1- Set the goal(s): A clear, concise and well-defined goal statement is the first element of any strategy. Using AI as an example; a crisp goal statement could read: 2- Construct the pillars (upon which the strategy will be built):The pillars are the guiding posts that all Tracks and Activities will follow. For example, pillars could be: 3- Build the tracks (which are the roads to deliver for the pillars) Having defined the pillars, now it is time to define which tracks will be created to enable to strategy. These tracks are broad umbrella under which the Activities for each track will fall.Examples of tracks are: 4- Articulate the objectives for each track:For each of the tracks, you need to define one or more objectives (less than 5 to avoid ‘catch all’ ambiguity and dilution of objectives’ focus). As an example, for the AI innovation track, you could state as an objective: 5- Describe key activities for each objective: In order to make your objective statement a reality, you must now define the Operational activities that will deliver on the defined objectives. These are product and project-based set of activities that will be used to carry out the specific actions needed to achieve your strategy goals. For example: Once you define these activities, and to ensure excellence in execution and delivery, as well as validating alignment with strategy, you may want to use a framework such as the Peak Performance Framework for business alignment. This framework will also be the subject of a future discussion.
Business analyst role
In product design and development organizations We previously discussed the Peak Performance Framework for Business Alignment. One of the key roles in the model is that of a Business Analyst. Today, we illustrate the role and its relationship to others graphically. We assert that the role of a business analyst is to produce clear, well-articulated use cases. A classic example of good use case comes from the automotive industry: Citroen is a French car company, and in the late 30’s. its managing director wanted to build a car to meet certain strategic objectives. He gave his design team some specific use cases for the desired car! Use case 1: The car must be able to cross a freshly ploughed field with a basket full of eggs on the passenger’s seat without breaking them Use case 2: It must enable four people to transport 110 pounds of farm goods to market at 30 mph, and if necessary, across muddy, unpaved roads. Use case 3: The car would have the fuel economy of 80-95 mpg. Use case 4: A farmer must be able to sit in the car without removing his hat. Use case 5: The farmer should be able to purchase the car with revenues from one season’s crop sale In these use cases, no technical requirements for the mechanical design, shape, or the materials used was given. This is the role of the Requirements Analysts. Designers, and Engineers, as well as Finance and Marketing specialists.
Lessons from the St. Louis Arch
What can the St. Louis Arch teach us about IT management!
Why do IT projects fail?
Projects fail for many reasons. We have compiled a list of the more common ones. The list is by no means exhaustive, but it covers a broad number of issues, from people to process and technology. Recognizing the reason(s) for failure is the first step is turning around a failing project, which is the subject of our next blog: Lack of alignment with business strategy and roadmap Lack of executive involvement Lack of stakeholder involvement. Unclear requirements or poorly defined change management process Lack of resources, turnover of key resources, or poor resource planning Team dynamics issues Unrealistic schedule Planning that is based on insufficient data, missing items, insufficient details, or poor estimates Unidentified or poorly managed risks Poor project tracking and communication Development methodologies selection and processes Technology issues Other reasons? We welcome your comments!
Decisions … Decisions!!!
How do you make business decisions? Which projects gets prioritized, how do you make build vs. buy, purchase decisions, etc.. Project Heroes has built a decision support tool that takes the emotions and the guesswork out of important business decisions. You can use it for: ■ Portfolio selection ■ Ideation and new product development ■ Project ranking and selection ■ Build vs. buy decisions ■ Budget distribution ■ Site selection ■ Vendor sourcing and selection ■ Strategic planning ■ Risk Management ■ Sales planning ■ Curriculum development ■ Hiring decisions Check the tool out here: https://DecideMeNow.com To request a free demo, please contact Project heroes!
When Agile Is Not: Three reasons where things go wrong before they start
Interest in Agile development is at an all-time high. It is estimated that over 85% of organizations have some type of Agile implementation, a pilot, or are planning on introducing Agile. In a previous article, we discussed how implementing Agile without the three necessary pillars of Division of Labor, Platform Rehabilitation, and Component Development architecture will only result in getting ‘Bad Things’ get done Faster. This certainly is not the purpose of Agile. In this article, we shift gears to Agile team structure and operations. Our experience and observation has led us to these 3 key points: The Scrum Master: In simple to medium development project, the traditional scrum master role of a facilitator works well. However, in complex technical projects, and in large environments, the scrum master needs to be more than a facilitator. He or she must have a good understanding, and perhaps expertise in enterprise architecture and software engineering. Not that the scrum master will play the role of an architect or engineer, but because in a complex project, they need to be able to identify challenges and reach out or requisition to the right resources in order the keep the cadence on track. This essentially extends the role of scrum master into a consultant and an advisor. The Product Owner: The business reality is the tyranny of the urgent trumps the important. Often, the designated ‘product owner’ role is handed off to “someone who has time”, and not necessarily one who know exactly what the product need to do, and how it should function. The result is re-work, delays and waste of time. Not at all what people expect from Agile. To remedy this, we have proposed and implemented a Product Owner role qualification that is a cross between a business architect and a product manager The Framework: In smaller organizations, individual Agile development activities work well. However, in larger enterprises, connecting and coordinating tens, hundreds, or even thousands of Agile projects REQUIRE coordination on all levels; technical, fiscal, governance, systems, compliance, strategic, and operational. To accomplish this, an Agile framework (eg; Scaled Agile – SAFe) needs to be in place to tie it all together; enterprise portfolio, enterprise strategy, financial planning, resource management, business/IT alignment, and other aspect or enterprise activities.
Strategy vs Planning vs Strategic planning
The words ‘Strategy’ and ‘Strategic Planning’ and sometimes even just plain old ‘planning’ are often used interchangeably. In fact, they are not the same, and should not be confused with one another. Strategy: in its simplest definition, strategy is WHAT you need to do to get from where you are to where you need to be. Essential for the success and realization of the strategy is a Road Map that explicitly states what and when actions will be taken. This road map will produce a Portfolio of Projects and Initiatives, as well as the necessary financial and other resources needed to turn this road map into a reality. All of these must be aligned with the Strategy, and carried out through a careful Plan that articulates cost, timeline, resources, risks and challenges, and a mechanism for change management. Strategic Planning is this essential process mentioned above. It involves creating a Road Map, a Portfolio of (investment) Projects and Initiatives. Closely tied to Strategic Planning is Change Management where people, culture, processes and technology need to be examined and changes made as necessary. Planning or Project Planning is the disciplined process by which explicit tasks, resources (human, time, financial, machines, soft assets, etc…) are carefully integrated to accomplish the goals of one or more project or a portfolio of projects. Integral to project planning is Outcome Measurements. Many project management practitioners measure the success of a project based on the ‘cliché’ of on-time and on-budget. Although this is not a bad thing to measure, the reality is, most projects morph and change from their initial state and goals. When evaluating the outcome of project, one must ask these two questions: 1- Have Things been done Right: This the discipline of Process Improvement through lessons learned, and it is a Management responsibility. 2- Have the Right Things been done?: This is where mapping the outcome of the project to strategy is critical. You may have done things right, but was it the right thing to do, based on your organization’s objectives and strategy? This is a Leadership responsibility.
The Fallacy Of The Iron Triangle
We have all heard about the Iron Triangle; Good-Fast-Cheap, pick two! True, very true, but that was back when a mobile phone meant the police car radio, gas was 65 cents a gallon, and owning a 19” color Sony Trinitron TV was very cool. The Iron Triangle is not, and can’t be true in 2019. Advances in software engineering methodologies, architecture, tools, and platforms, and a very skilled workforce negated the false necessity of the Iron Triangle ‘pick 2’. Another reason for the ‘rusting’ of the Iron Triangle is the business demand for a more efficient and effective software engineering output. It is no longer acceptable, or tolerated to hide behind the ‘pick 2’ mantra.
Project managers code of ethics
Project Managers Code of Ethics Work approach: As project managers, our work approach is grounded in our code of ethics: As practitioners of project management, we are committed to doing what is right and honorable. We set high standards for ourselves and we aspire to meet these standards in all aspects of our lives – at work, at home and in service to our profession. Responsibility Our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result. Respect: our duty to show a high regard for ourselves, others and the resources entrusted to us. Fairness: our duty to make decisions and act impartially and objectively. Free from self-interest, prejudice and favoritism. Honesty: our duty to understand the truth and act in a truthful manner both in our communications and conduct. Setting us up for success: Trust: We trust each other, rely on that same trusting relationship with our customers. Respect: WE respect our colleagues to maximize their contribution. This means respecting the integrity of our project structure – allowing us to do our best work.