Skip to main content

Tag: Requirements

Effective Project Management Without Apps

If you want a really good project outcome, close down your PM apps and tools for a few days, and just reflect on the nature of the new project you’ve just been handed!

As with most things, successful projects start with well-considered preparation. Here are a few suggestions as to how you can give your project the best chance of success before you open any apps.

These suggestions are largely pitched at infrastructure and building projects, but most of the comments hold true for ICT and process improvement projects as well.

What is success for your project?

→ Establish clear agreed project objectives and measures.

What is “success” for your project? How will you know when you’ve got there? Have you agreed on the project objectives and risks/constraints with the project sponsor?

All successful projects, whether they are engineering and building projects, ICT development projects or less tangible social development projects, start with clear agreed objectives and performance measures. In fact, the more intangible or qualitative the desired outcomes, the greater the need for clear objectives and measures.

The objectives should be project specific so that they are achievable within your accountability, rather than corporate objectives over which you have limited influence. You may need to re-work the project objectives so that they adequately describe the desired project outcomes, and are measurable and achievable within your accountability.

How “carte blanche” is your delegation and accountability?

→ Seek the maximum level of delegation to communicate, and clarity on approval to commit.

How far does your delegation extend? What can you commit to without seeking approval? Have you actually obtained any meaningful written delegation?

Effective project management requires the PM to be able to interact and collaborate across the whole organisation, and hopefully across the broader external environment, without travelling up and down the organisation hierarchy each time you need to communicate with key players in the delivery chain.

The key point here is to maximise your delegation to communicate widely, and not necessarily to make momentous or fundamental decisions. The latter is managed within the project’s governance framework.

How effective is the project’s governance framework?

→ Assist the organisation to operate an effective project governance framework.

It’s important to remember that the PM’s role is to deliver the project successfully, and not to invent project content or make arbitrary scoping and specification decisions. Accountability and decisions regarding project funding, scope and specifications are the role of the organisation, communicated via a project governance framework to which project management activity should be ultimately accountable.

You may have to assist the project sponsor to develop an effective project governance framework, identifying the ultimate accountability chain, and the key corporate players who have organisational accountability for funding, scoping, legal support, communication and technical compliance.

Whilst the existence of a corporate steering committee or similar may sometimes appear to be a burden from the PM’s perspective, if the project starts to experience difficulties, especially with stakeholders, then the governance framework will be of immense value to keep the project on track.

How mature is your organisation with respect to project management?

→ Recognise the level of project management maturity in your organisation.

PM maturity (the ability and structure to support effective project management) within an organisation is a key success factor. Mature organisations provide effective policy and guidelines for project management, low barriers to cross-functional communication (the near absence of silos and fiefdoms), and a range of templates and support material. The organisational role and status of the PM is understood and accepted. Organisational relationships are clear, and the staff are at ease with the duality of functional and process accountabilities.

On some occasions, the organisation’s project management maturity will be less than desirable, and unfortunately, this is an area that the individual PM can do little about directly. The best you can do is to recognise any management shortfalls and create your own systems and templates as you require. You may then be able to lobby for the organisation to accept your systems corporately.

Where did this project come from?

→ Understand the genesis of your project, and its associated risks.

Take some time to consider and identify the genesis of this project. Was it born out of careful planning, or was it hatched as a knee-jerk reaction to a perceived threat? Does the project have demonstrable corporate and stakeholder support, or is support a bit tenuous and narrow?

How is your organisational life as a PM likely to fare over the project lifecycle? Have you been handed a poisoned chalice, or a great opportunity just waiting to be delivered?

It’s important to understand the genesis of the project so that you can position yourself and your team accordingly. A thorough understanding of these aspects should also lead to the generation of project risks associated with the project’s history and climate, so that any difficult issues can be identified in advance and managed effectively.

How much prior documentation exists?

→ Identify and acknowledge all previous project documentation.

The amount of prior documentation will depend on the point at which the PM was invited to commence. Mature organisations appoint their PM early in the project lifecycle, and the PM will be there to see the development of the project development plan and procurement plan. It is likely that the business case will already have been finalised.

Whatever your point of entry, it’s critical that relevant project documentation exists, and that this documentation embodies the intent and legitimacy of your project within the organisation. The PM may have to initiate action to ensure that this documentation is formally signed off and published. The PM should also ensure that any gaps or unqualified risks are identified, acknowledged and rectified prior to proceeding with the project.


Advertisement
[widget id=”custom_html-68″]

Are the project expectations realistic?

→ Understand the features and realism of the organisation’s project expectations.

The chances are that the business case that launched the project was developed and written by someone else. That someone else may have been an excellent business case writer, but they may also have carried forward some highly optimistic expectations for the project, including the budget and the benefits. Also, consider that often the business case author may not carry ultimate responsibility for project delivery.

There are several key factors that may lead to undue optimism. The first is standard optimism bias, which can understate the required budget and overstate benefits by at least 20%. The second factor is the human condition of being “eager to please”! Organisations or individuals that are eager to satisfy political or corporate expectations may trim off cost estimates, exaggerate benefits, and minimise risk contingencies in order the get the project over the line. The third factor is the preliminary state of the scope and design at the time of seeking approval for funds, meaning that the budget is based on a very thin concept design that would not normally be used for cost estimation. How thorough was the investigation and preparation for the project? Was the business case based on a thorough feasibility study, or was the feasibility planning skipped because of indications that the sponsor government or organisation wanted the project outcomes anyway?

Any unrealistic expectations or assumptions need to be highlighted and remedied before the project gets into its stride, otherwise, the PM will be continually perceived to be under-delivering.

What are the current expectations?

→ Ensure that project expectations and assumptions are contemporary.

If the project has been in gestation for a while the business case and any project planning material may not be current, and circumstances may have changed. The political or organisational climate may have moved on. The supplier market may have changed. Other projects or initiatives may have changed the risk profile of the project.

A brief review of the project documentation against the current landscape is valuable to give the PM confidence that the project is still viable. If there are any assumptions that don’t appear to hold up in the current climate, then this is the right time to flag them, and to seek modifications before the project builds up too much momentum.

Who are the key influencers and beneficiaries?

→ Stakeholder engagement planning is critical to project success.

Before getting too carried away with delivery planning, it’s worth reflecting on the nature of the key stakeholders. The stakeholders should be categorised in terms of key influencers (positive and negative), important technical support, passive communities and the ultimate beneficiaries.

With the rise of communications through social media, a relatively recent phenomenon is the impact of the “nimbys” – “not in my backyard” protesters. Major projects that deliver broad scale benefits can be derailed by a vocal nimby group, especially in swinging political electorates.

In addition, there are broader scale support or protest groups for virtually everything – building development, infrastructure development, environmental impact, education, social welfare, equality and more. These groups can mobilise very quickly, and the PM may be caught unawares through lack of stakeholder planning, or just simply naivety.

The development of a relevant and detailed stakeholder management & engagement plan is an essential first step in project delivery management. If the project involves internal process improvement, then the plan should morph into a detailed change management plan.

Who’s helping and who’s hindering?

→ Informally test the organisation climate for project support.

Check within the organisation to assess who’s helping and who’s hindering. Ideally, all key organisation personnel will be aligned and committed to the project, but it shouldn’t be taken for granted. Moreover, the alignment or non-alignment of key staff may not be overt, and written documentation and sign-offs may not tell the whole story. The PM should spend some time informally testing the organisational waters for any latent internal issues that may arise as the project is delivered.

You may have to develop an internal strategy to enlist the support of key organisation players to help manage and persuade the less committed internal stakeholders.

What are the key procurement and delivery risks?

→ Ensure that the project risk register is realistic and specific.

The project documentation will almost certainly include a comprehensive risk analysis – often so comprehensive that the really key practical risks are lost in amongst dozens of modest risks, or perhaps not accurately scored by the project planners. Often, the identified risk events and mitigation actions are too generic to be of much value, and they may have to be revisited to add project specificity. On occasions, some risk events may have been copied and pasted from other projects.

Check the extent of identified procurement risks and their practicality, and the risk score that has been attributed to the risk. Sometimes a thorough revision of the risk register is worthwhile, with assistance from procurement and delivery personnel. In fact, it is good practice to revisit and review the risk register at every new phase of the project, including post business case, project development plan, and then at the inception of the delivery phase.

How committed is your team?

→ Establish a competent and diverse project team.

How committed and competent is your team? Or have you actually even acquired a team yet? The team mix is extremely important. If you still have the luxury of nominating your team members, then try and ensure that the team comprises a suitable mix that demonstrates real diversity including technical orientation, process orientation, financial, social and environmental. Consider that the core full-time team could comprise a mix of generalist process-oriented and outcome-oriented people, supported by a part-time team of competent personnel representing each of the required professional disciplines. Lastly, avoid a predominance of alpha males!

The role of the Project Director

The more project-mature the organisation, the more likely that it will support the role of a Project Director (PD) who may manage a portfolio of projects each led by a subordinate PM. Or in some cases, the project may be of such size and/or complexity that a PD is appointed to a single project, supported by subordinate PMs.

If there is a PD appointed, then many of the activities identified in this paper are more likely to be directly pursued by this person, but the support of the PM is expected and necessary, and the PM’s role in these activities may not be diminished.

The role of the PMO

If your organisation is project management mature, then it is likely that it supports an effective Project Management Office (PMO) to provide the project management framework, guidelines and tools for PMs. Make the most use of their facilities, ensure your team’s compliance, and seek their personal help in managing your project structure. Don’t be shy in offering suggestions for improvement based on your practical application of their tools.

Celebrate little wins!

The daily work life of a PM and their team can be extraordinarily stressful and unrewarding, especially if some of the elements discussed here are absent. Your project will have “milestones” identified along the way, and you should take the time to celebrate the little wins as you proceed and acknowledge the work of yourself and your team as often as possible!

OUTSIDE THE BOX Forum: The Iron Triangle is Obsolete – Long Live the Scope Triangle, Part 2 of 2

The Scope Bank is unique to the Effective Complex Project Management (ECPM) Framework, and it functions as the traffic cop and depository of the solution discovery and development history.

The Scope Bank is the clearinghouse for all project activities. It brings together in one place solution status, cycle performance history, potential solution components and a foundation for cycle management of the project. It is the basis for problem resolution, decision making, resource management and just-in-time planning.

The Scope Bank is always up to date at decision time. In the ECPM Framework, the Scope Bank is much like a tool whose purpose is to direct the deliverables coming out of all completed cycles and plan for the deliverables to be developed in the following cycles.

Scope change requests will arise at any time during a cycle but their resolution is held until the cycle is complete and its deliverables reviewed. There will be situations where an ECPM cycle is not completed. In these situations, the deliverables that were not complete are returned to the Scope Bank for further prioritization and scheduling. The ECPM Framework cycle duration is sacrosanct. It ends as planned and not an hour later.

The Scope Bank has been a major artifact of the ECPM Framework and has every indication that it can bring added value to the processes and practices of its projects.

SCOPE BANK

The Scope Bank is the single depository for the current requirements. It contains open change requests, the current solution, and all learning and discovery that has been accumulated from all cycles that have not yet been acted upon. This includes all unresolved change requests. The Scope Bank is unique to the ECPM Framework and is an essential part of the portfolio of tools, templates, and processes that support the ECPM Framework.

Nothing should ever be removed from the Scope Bank unless it is built into the solution. So, it still remains in the Scope Bank but from a different perspective. An idea once suggested and thought to be of no use early in the project might later turn out to be just the opposite. In some cases, I have seen a previously rejected idea suggest a new idea that leads to new features and functions added to the solution. So, the message is that every idea is a good idea, we just haven’t figured out how – yet! If it isn’t in the Scope Bank, it will have been forgotten and no longer of any value to the solution.

The Scope Bank is the primary input to the Client Checkpoint in the ECPM Framework. The contents of the Scope Bank are updated at the completion of each cycle. The contents include future Integrative Swim Lanes and ideas for future Probative Swim Lanes. Since there are fixed resources for the next cycle, the contents of these two types of swim lanes must be jointly prioritized. Depending on the degree to which the solution is complete, there will be a healthy mix of the two types of swim lanes.

The process of discovery and learning by the team is continuous throughout the cycle. Any new ideas or thoughts on functionality are simply recorded in the Scope Bank and saved for the Client Checkpoint Phase. The Scope Bank can physically be a list posted in the Team War Room, or some electronic form (spreadsheet or word processing document). Whichever form you decide to use, make sure it is always visible to the team.

For the cycle just completed, the cycle plan called for a specific list of functions and features to be added to the deliverables through one or more Integrative Swim Lanes. No schedule or scope changes were allowed during the cycle, yet it is possible that not all the planned functions and features actually made it into the deliverables. There are several reasons for that, which we will not discuss. They are obvious reasons (e.g., schedule slippages that could not be recovered, a discovery that rendered the functionality unnecessary), which occur in all projects. The ECPM Framework accommodates these anomalies without skipping a beat. Any functions or features not completed in the just-completed cycle are returned to the Scope Bank and prioritized for consideration in a future cycle.

SCOPE BANK CONTENTS

The following presents a brief discussion of each of the items that are in the Scope Bank at any point during the project lifespan. The item descriptors listed above are most useful for scope change requests and processing but otherwise are provided as appropriate.

Current Solution

Complex projects are high-risk projects. That means they could be delayed or even terminated at any point in time. To minimize any potential business losses every cycle ends with an updated production ready solution. That solution is not complete but at least any business value that can be generated from it will be generated if the project is terminated and the solution deployed. While the expected return on investment for a completely acceptable solution may not have been realized at least there is some return on investment.

There are several factors that are at play for a favorable deployment decision. Three are important here:

  • The Enterprise Release Schedule
  • The Business Value from the Current Solution
  • The Challenge of Deploying the Current Solution
    • Support costs for multiple solutions
    • Frequent process or practice changes
    • Maintaining multiple versions of documentation

Requirements

Plan-driven project management models include complete requirements specification as a pre-requisite to the planning effort. That has forced guessing which leads to several requirements revisions during project execution and hence to plan revisions. There is a lot of waste and non-value-added work in such approaches. This is not in keeping with lean practices.


Advertisement
[widget id=”custom_html-68″]

Requirements and their elicitation have been a major obstacle to project management for several reasons:

  • In the complex project landscape, the upfront identification of requirements is unlikely because either or both of the goal or solution are usually not completely known.
  • Complete requirements specifications are learned and discovered during project execution.
  • The world is dynamic and ever-changing and doesn’t stand still just because you are managing a project.

The ECPM Framework has mitigated this obstacle by modifying the accepted definition of a requirement. This definition begins with a high-level description of what an acceptable solution must provide from a performance aspect. In some cases, it defines what an acceptable solution must contain without any performance criteria added. To wit:

DEFINITION: ECPM Framework High-level Requirement
A specific end-state condition whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization. 
The set of ECPM Framework high-level requirements forms a necessary and sufficient set for the attainment of all project success criteria and the delivery of the expected business value.

At any point during the project life span the solution is such that requirements are either:

  • Integrated into the solution
  • Under development for future integration into the solution
  • Not yet approved for integration into the solution but requires further study and analysis
  • Unlikely to be integrated into the solution without compromise

Change Requests

Every cycle will result in new learning and discovery. This will result in requests for changes to requirements, functionality or other project adjustments. The changes might suggest changes to what has already been identified for addition to the solution or changes to potential solution components. They will usually arise from the client members of the project team. The intake process involves documenting them and adding them to the Scope Bank following the cycle in which they first arose. This list is cumulative and includes:

  • Change requests not yet acted upon
  • Change requests scheduled for integration
  • Change requests in the solution

Integrative Swim Lanes

Once a deliverable has been approved for integration into the solution it is prioritized along with others to be included in the solution. That prioritization is usually business value based but other technical considerations will usually determine the cycle in which it will be included.

Built and scheduled for integration

Much like any Scope Change, the schedule is based on technical rather than business criteria. There will be exceptions when the expected business value or marketing benefits exceed the cost of implementation.

Integrated into the solution

It is important that the history of integrated change requests be kept for later reference. Project performance reports may well quantitatively compare that history at the cycle level.

Probative Swim Lanes

Probative Swim Lanes are unique to the ECPM Framework. They include a variety of experiments and other research projects. Most statisticians would see Probative Swim Lanes as just another design of experiments. I am one of those statisticians and would call Probative Swim Lanes primitive designs of experiments. Whatever you choose to call them, the idea here is to preserve the lean characteristics of the ECPM Framework. Probative Swim Lanes are often one of the following:

  • prototyping – trying out a number of ideas using different models
  • brainstorming – discussing alternatives and formulating approaches
  • researching – gathering information on possible approaches

The incremental search for a solution is that Probative Swim Lanes are sequentially linked. The objective is to spend time and money incrementally as ideas develop and earn further expense and time allocations rather than all at once on an untested idea. This is in keeping with the lean characteristics of the ECPM Framework.

Completed but not yet acted upon

Probative Swim Lanes can result in either solution increments to be built (future Integrative Swim Lanes) or result in dead ends (Probative Swim Lane Archives). In both cases that history must be preserved. It is the best intelligence the project team will have as far as suggesting and executing future Probative Swim Lanes.

Active investigation

The history of a single Probative Swim Lane may include several efforts. Not until a decision is reached is that effort reaches a decision point.

Defined but not yet been scheduled

Probative Swim Lanes that result in future additions to the solution have to first be added into the prioritized Integrative Swim Lane list.

PUTTING IT ALL TOGETHER

The Scope Bank is the solution history of the project from its inception. The plans and deliverables from all of the completed cycles are recorded there. All of the change requests and their resolution are also documented. Cumulatively this information is the best available for cycle planning.

OUTSIDE THE BOX Forum: The Iron Triangle is Obsolete – Long Live the Scope Triangle, Part 1 of 2

The Scope Triangle is an interesting artifact of project management planning.

The term is not used in PMI’s PMBOK® Sixth Edition. The closest the PMBOK comes is to list scope, quality, schedule, budget, resources and risk as the constraints that impact the project. PMBOK goes on to say that these constraints form an interdependent set in that if one changes at least one other will be affected. In this 3-part article paper we will develop the Scope Triangle and show how it can be used in project management training.

Representing the Project

There are two ways to graphically envision the project that have been described in the literature. They are briefly described below.

The Iron Triangle

I cannot find the source for this term but it has come to mean the relationship between cost, time and scope (Figure 1). As is the case with the six constraints identified in PMBOK these three constraints also form an interdependent set. Specify any two and the third is determined. Or to put it another way if your manager says something like “I want you to develop a web-based order entry system for the new widget line and I will need it operational in 2 months. You have a budget of $50,000 to cover all one-time development costs,” you probably can’t do it. The chances that these three constraints form a consistent set are unlikely. Better would be “I need you to develop and order entry system for the new widget line and I need it operational in 2 months. How much will it cost to develop?”

wysocki 07092018aFigure 1: The Iron Triangle

While Figure 1 may be an intuitive way to envision the project plan it has little value in project execution.

The Scope Triangle

The Scope Triangle (Figure 2) was first introduced in my training programs in the 1980s and subsequently published it in the first edition of my book “Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget,” (Wysocki, Robert K, Robert Beck, Jr. and David B. Crane, 1995, New York, NY: John Wiley & Sons, Inc. ISBN 0-471-11521-5). The intention then was to illustrate with a simple graphic that the project plan was a system in balance, at least on day one of the project.

wysocki 07092018cFigure 2: The Scope Triangle

The interpretation is rather intuitive, which is why there has been excellent instructional value in using it. The Scope and Quality are exactly bounded by the length of the three sides of the triangle representing cost, time and resource availability. Don’t try to draw the Scope Triangle. It is conceptual only. Given that the project plan makes sense on day one of the project the project plan is a system in balance. If any one of the five variables changes, at least one other variable must change in order to restore balance to the system. For example, if the client changes the due date of the deliverables to an earlier date, the length of the time side is reduced and the three sides no longer enclose Scope and Quality. To restore balance to the system anyone of several variables could change. For example, Scope could be reduced or the budget increased to hire outside contractors or some combination of the two.

Figure 2 is a useful way to envision the project plan and it has good value in maintaining the project plan, handling problem situations and managing scope change requests as is discussed below.


Advertisement
[widget id=”custom_html-68″]

Using the Scope Triangle as a Management Tool

The Scope Triangle has been used in training programs for over 25 years. It is a good model in which to imbed and teach the following three project management activities.

Managing Scope Change

In the traditional approaches to project management a formal scope change process is needed. Most processes start with a request from the client. The appropriate team member will analyze the request and issue a Project Impact Statement in which alternatives and their impact on the project plan are documented. The client chooses one and the project plan is updated to reflect the chosen alternative.

The Scope Triangle is used to prioritize the alternatives from those that affect only the project team and the resources it controls to those that affect the resource managers to those that affect the client through added cost or schedule adjustments.

Resolving Problems

Problems are sure to arise in even the best planned projects. Schedule delays, supplier shipment errors, loss of a scarce resource and a variety of risks that materialize and must be handled. There is a hierarchy of resolutions (related to the Scope Triangle) that are offered in the order listed:

  • Accommodated within project resources and timelines
  • Accommodated but will require extension of deliverable schedule
  • Accommodated within the current deliverable schedule but additional resources will be needed
  • Accommodated but additional resources and extension of deliverable schedule will be needed
  • Accommodated with multiple releases and prioritization of deliverables across release dates
  • Cannot be accommodated without significant change to the project

Representing the Project Portfolio

Recent application of the Scope Triangle deal with some basic concepts of project portfolio management especially agile portfolio management. In the Scope Triangle shown in Figure 2 replace the inside of the triangle with all of the projects vying for inclusion in the portfolio. The initial proposed projects will most likely require more time, or money or more human resources available at that time.

wysocki 07092018bFigure 3: Project Portfolio Management

Think of removing the proposed projects in some reversed prioritized order until each of the three bounding constraints are all met. The prioritized order will be based on some combination of risk and business value.

Putting It All Together

The Scope Triangle is a valuable tool for teaching scope management, problem resolution and portfolio management concepts. It is an intuitive graphic that every project manager should burn into their brain to help them approach the three applications with a much better strategy.

Never Make the Project About the Technology

Is that cutting edge Cybersecurity technology making your CSO drool and ready to pay boo coos of internal dollars on a bleeding edge tech project to showcase at the next user conference or Black Hat digital security convention?

Is that latest platform recently available to showcase your web apps on recently available and ready for you to use?

Making a project come to life because of the technology that an executive wants to try or wants to say that his division is using is a bad reason to have a project. And I feel it goes against some sort of unwritten code of ethics for project managers but I will get to that in another article, most likely (these ideas have to come from somewhere).

Here’s my take… never ever ever ever make the project about the technology. It can be awesome. And it can be disastrous. You can end up being in the latest tech magazine and your stock may soar. Or you may end up on the heaping pile of Ryan Leaf NFL busts in terms of tech failures. You may find that bust lands you with a headline on CNN about a tech startup losing a billion dollars on a failed project to implement a new security solution that ended up in security breeches, identity theft and lawsuits because your tech team wasn’t quite ready to handle such a project. But then again, they say “there is no such thing as bad publicity” – there is always tomorrow to fix it or capitalize on it. Unless of course this bad decision put you out of business. Then there is no tomorrow.

So what do you do when it appears that the customer or your senior management wants to jump in head first because of the technology? For me, it comes down to these three things…

The end does not justify the means.

Getting there isn’t really half the battle. Getting there successfully with the right solution is the whole battle – the whole project. There is no half battle or partial project. It’s all or nothing. It’s not about the right process or the coolest technology or the headlines… good or bad. It’s about the successful solution. I had one organization I was leading a project for where the client company was so excited about our solution we were implementing – the first of it’s kind in their industry – that they went ahead and published go-live dates in a major industry publication under assumptions made with and by the account manager in our organization who sold them the project.

Unfortunately, those dates became the hard and fast – or “drop dead” – deliverable and implementation dates that I had to build my project schedule backwards from in order to complete and meet the deadlines. There were no other options and no option for me to put together the realistic schedule that I knew and my team knew we could meet safely and accurately. What happened? My team and I found ourselves working onsite at the customer location for two weeks just before Christmas working through issues to get to go-live on time. Blew through money (beyond budget) faster than Usain Bolt can run 100 meters, but we made it!


Advertisement
[widget id=”custom_html-68″]

The desired technology may not be right.

The obvious problem is that the desired technology – this bleeding edge choice for the solution – may not be the right technology. The project team needs to understand business processes, what the “as is” environment is and what the desired “to be” environment should look like and figure out if the customer’s perception of the project is the true need or if the project is bigger (or smaller) and the customer request or need is merely a symptom of the real project. Then, and only then, can the project team step back and formulate the real project. Following that, they can – with the customer’s input – identify what a technical solution should look like including what the proper technology to implement really is. Still hopefully a cool one, but it may not be what the customer is hoping for. “Backing into” the solution from the technology is the wrong way to go… it’s like reading English from right to left… pretty painful… bad outcome… headaches.

The skill set may not be there.

Finally, the team may not have the skill set to implement the desired technology. That doesn’t mean it can’t be done. But it probably can’t be done without a change order to get the right resource or resources onboard – at least temporarily and probably expensively – for this specific project. Don’t get me wrong, implementing a bleeding edge technology in any industry for the first time is feather in the cap of the delivery organization as well as a gem on the resume of the project manager, the business analyst and the entire project technical team. Win-win-win. And the customer organization comes out looking great, too. So if they want it, and it’s the right technology for the project team and the customer is willing to pay for it – or your organization can see the benefits of the end publicity – then go for it. The return on investment (ROI) for all involved to eat some costs will be high.

Summary / call for input

The project is the project. That’s what the team needs to focus on. It’s like putting blinders on because sometimes the customer or senior management will interject their needs and desires and those may be in direct contrast to what is best for them and for the project – and they don’t realize it. Stay focused on the successful end solution while taking all these suggestions along the way, but resist the urge to act upon them. At least not until you’ve ensured that they are the best roadmap to success.

Readers – have you had customer project scenario where it was all about the technology and the success of a new solution? How did you calm the enthusiasm while you sorted through the need to determine if that was the best path for the project. You can just proceed with the customer request as is, but if you get to the end and implement something that doesn’t really solve the need, the onus is on the delivery team, not the customer.

Problem Pyramid™ Prevents Prevalent Problem Statement Problems

Problem statements are a widely-used and well-regarded technique. Yet, I find many fail to achieve the benefits attributed to them.

The powerful Problem Pyramid™ overcomes problem statement shortcomings to provide expected value to projects.

Many projects use problem statements and often include them within a project charter. Defining the problem before undertaking its often-costly presumed solution is sound conventional wisdom—in theory. After all, no less a theoretician than Albert Einstein is often attributed saying to the effect that if he had only one hour to save the world, he would spend fifty-five minutes defining the problem, and only five minutes finding the solution.

Another widely-cited source of insights, Yogi Berra, said, “In theory there is no difference between theory and practice. In practice there is” (BrainyQuote.com).
In practice, problem statements tend to be what I call “conventional we’s dumb.” Many if not most actual problem statements not only give merely the illusion of soundness but also often outright mislead. Moreover, too often they become simply templates as substitutes for understanding.

Typical Contents

Sources seem to agree that a problem statement should state what the problem is, how bad the problem is, the value to be obtained from solving it (why), and its general expected solution (how). Frequently the why includes identifying those with the problem who need a solution. Some also emphasize the importance of quantifying the problem and/or its solution’s expected benefits (how much).

Projects often go awry when they focus on solving the wrong problem, or when they take mistaken actions because even the right problem is not adequately understood. Thus, problem statements are intended to increase chances of project success by assuring the project is solving the right, well-understood problem.

Too often, though, execution in practice falls short of those laudable purposes. An inaccurate or misleading problem statement in fact can contribute to exactly the types of project mistakes it was intended to prevent.

Actual Contents Issues

Far more than realized, problem statements describe the wrong—or at least not right—problem. Accurately defining the problem turns out to be much harder than generally assumed. Twelve people describing ostensibly the same situation often state a dozen different problems, and they still all may be wrong. What they call a problem instead could be symptoms, causes, measures, presumed solutions, or something else.

Yet, most conventional problem statements I’ve seen simply take as given whatever someone has declared to be the problem. When that someone is a higher-up, as often happens, their declaration of the problem is even less likely to be questioned.

Many problem statements I’ve seen are mainly venting, frequently piling on about how awful the problem is. Of course, the worse the problem is made to seem, the more likely a project will be initiated to achieve the proponent’s proposed solution and the less likely their proposed solution will be evaluated critically. Not surprisingly, proposed solutions almost always are intended to benefit the proponent most but frequently are ill-conceived and fail to deliver the proponent or the organization expected value.


Advertisement
[widget id=”custom_html-68″]

Problem Pyramid™ Overcomes these Issues

The Problem Pyramid™ is a powerful six-step systematic disciplined tool for getting right the problem, its value measures, causes, REAL business requirements deliverable whats that provide value when satisfied, and a responsive product/system/software way how to satisfy the whats.

goldsmith 052818a

The steps/boxes need to be performed in numbered sequence, for each builds on the prior steps. Moreover, we don’t proceed from one step until it passes serious scrutiny to be sure it is correct. For each step we apply a number of disciplined evaluation guidelines that give far greater confidence it’s right before going to subsequent steps that depend on it.

For instance, with conventional problem statements, the problem seldom is meaningfully evaluated or even questioned; and management oversight, if it exists at all, usually consists of pointlessly asking the problem statement’s author whether they’ve correctly identified the problem—they’ll always answer “yes.”

In contrast, the Problem Pyramid™ confirms Box 1 is a problem, Box 2 current and Box 3 goal measures accurately apply to it, and achieving the Box 3 goal measures in fact indicates the problem has been solved, opportunity has been taken, or challenge has been met, which in turn provides REAL value. When measures are not defined or don’t match the problem, the problem is usually wrong, and the measures often are too.

Box 4 causes are the as is (or current state) process producing the Box 2 current measures that tell us we have a problem. We confirm Box 4 identifies all key causes and that together they reasonably explain why we have the Box 1 problem.

Box 5 describes the should be (or future state) process top-level REAL business requirements. We confirm these are business deliverable whats that when delivered, satisfied, or met reasonably will achieve the Box 3 goal measures and thereby provide value. We also confirm the Box 5 should be whats reduce or eliminate all the key Box 4 causes so the problem won’t persist.

Box 6 describes a product, system, or software way how to satisfy the Box 5 whats. We confirm the Box 6 how in fact will reasonably satisfy the Box 5 whats and thereby provide the Box 3 value. Most projects creep and fail because they start with a presumed Box 6 product how which turns out not to satisfy the Box 5 REAL business requirements whats that provide value when met, usually because the Box 5 whats have not been defined adequately, if at all.

The Problem Pyramid™ guides accurately identifying the REAL problem and providing REAL value by reducing/eliminating its fully-identified key causes. Moreover, the Problem Pyramid™ assures ordinarily-overlooked REAL business requirements deliverable whats that provide value when satisfied in fact are identified adequately and will reasonably be satisfied by a responsive product/system/software how.