pmNERDS Community: Login

  • Innovation_e_Publication
  • Integrated_PM_Feedback_Blog
  • Job_Board
  • pmNERDS_Center_of_Excelence
  • Research_and_Development_Journal
  • Community_Blog
A+ A A-

An Integrated Project Management blog post within the category of Process Management used to increase competitive advantage.

Problem Definition Structure


   Of course, I understand the desire to jump right into production, but I also understand the wisdom in stepping back and gaining an understanding the problem before trying to solve it. Right, I've heard all about cut/measure ratio. Like in many controversies, this is a false dichotomy. Turns out that depending on your business strategy, industry, and product, typically as much as 60% of all market needs gathered have straight forward solutions with no problems produced. I suppose before I say there are no problems, we should agree upon what a problem is.

   The first attribute of a problem is the need for change. All problems have a current state, and a desired state that is different. The transition from the current to the future state may have nothing preventing it, it's just a matter of doing it. But wait a minute, when we say 'nothing preventing it', does that include resource availability, enough time, and investment? These types of things can also constrain our journey from the current state to the desired state. This introduces the notion of types of problems like business, market, user experience, and technical problems.

   The second attribute of the problem is the resistance to the transition between states. The greater the resistance, the greater the problem. Some problems stem from technical resistance, others cultural resistance, while still others a business resistance. You'd be surprised by the number of problem statements I see that never state the resistance or conflict caused by trying to transition between states. Every problem statement should identify the conflict. Without a conflict, it's at best an enhancement request, not a problem statement.

   The last paragraph implied that problems produce varying degrees of resistance between states. The third attribute of the problem is the quantification of this resistance. Just as you may experience different resistance traveling the different paths from point A to point B; the path you choose to get to your destination impacts the resistance experienced. The third attribute is the path your willing to take.

I find that the 'IF THEN' construct works well in explaining the need for change. An example might be, 'If I start my car, then my dog starts to whine.' Notice that this statement doesn't identify the desired state. Perhaps a way to avoid this ambiguity of what's desired would be, 'IF I start my car, THEN it should start without hurting my dogs ears.' Ok, so where's the resistance attribute in the statement?

   The resistance to the desired change is captured in the form of 'IF THEN, BUT'. Many times resistance isn't identified by the same people capturing the IF THEN component of the problem definition. With the example above, we've add, 'IF I start my car, THEN it should start without hurting my dogs ear, BUT low frequency starters wear out sooner, and require too much battery capacity.'

   Another construct that can be important is the 'IF NOT THEN, BUT'. Many organizations require both constructs in their problem definition process.

   The path is identified by placing the problem statement in different categories. The TRIZ methodology suggests five levels to problem solving aligned with the amount of resistance you are willing to accept. This triaging is the first step in maintaining a balanced opportunity pipeline. By properly categorizing the problem statement, into one of three portfolios or categories, you are able to reduce the number of full problem statements you need to write.

   60% of your problem definitions should be categorized as 'Maintenance & Utility' types, and only consist of the 'IF THEN' statement. These typically will be routed for Level 1 and Level 2 types of innovation. Level 1 uses no innovation, and is addressed through routine design problems solved by methods well known within the specialty. Level 2 requires minor improvements to the existing product using methods well known within the specialty.

   30% of your problem definitions should be categorized as 'Enhancement & Improvement' types, and consists of the 'IF THEN BUT' statement. These typically will be routed for Level 2 and Level 3 types of innovation. Level 2 requires minor improvements to the existing product using methods well known within the industry. Level 3 requires fundamental improvements to the product using methods well known within the industry.

   10% of your problem definitions should be categorized as 'Transformational', consists of the 'IF THEN BUT' statement, and also requires a new business case to be developed. The other two categories of problems are linked to existing business plans. Setting out to address these 'Transformational' type problems is going to require a business case and maybe modification to the product strategy. These typically will be routed for Level 3 and Level 4 types of innovation. Level 3 requires fundamental improvements to the product using methods outside the industry. Level 4 requires a new generation of a product that entails a new principle for performing the product's primary function.

   Level 5 innovation requires a new product innovation charter and is outside of the typical innovation team.

Continue reading
Recent comment in this post
Derick Workman
I find using the three categories of Maintenance & Utility, Enhancements & Improvements, and Transformational, to be a great way ... Read More
Wednesday, 10 May 2017 08:11
480 Hits
1 Comment

What is a Knowledge Management Architecture?

Here at pmNERDS we promote a Knowledge Management Architecture–Integrated PM.

The Knowledge Management Architecture is different from an Enterprise Architecture, but typically connects to it, so in some cases, they are confused with each other. The enterprise architecture emerged out of methods for documenting and planning information systems architectures, and currently most enterprise architecture practitioners are employed in the IT department of a firm. The enterprise architecture team performs activities that support business and IT managers to figure out the best strategies to support innovation–in relation to the business information systems the firm depends on. Enterprise architecture defines:

  • what an organization does in terms of business goals and objectives;
  • who performs individual functions within the organization,
  • how the organizational functions are performed within the innovation value chain;
  • and how information assets are is used and stored in support of that function.

EA is also referred as "Everything Aligned", as the Business-Technology alignment is achieved through EA tasks. The Business and Technology parameters like Availability, Scalability, Security, Interoperability, Maintainability, Lower Cost, Extendibility, and Reliability are improved through EA.

As pmNERDS go about making innovation a science, it is in the Enterprise Architecture that the categorization stage takes place.
The Knowledge Management Architecture is different from an Information Architecture, but again is sometimes confused with it. Information architecture (IA) is the art and science of organizing and labeling data including: websites, intranets, online communities, software, books and other mediums of information, to develop usability and structural aesthetics. It is an emerging discipline and community of practice focused on bringing together principles of design and architecture, primarily to the digital landscape. Typically, it involves a model or concept of information which is used and applied to activities that require explicit details of complex information systems. These activities include library systems and database development. (Wikipedia)

IA can be about making wireframes of a website, or the blueprints of a digital design, which are both a large part of the information architecture. An IA might also produce a taxonomy of how content and products on a website should be classified, or a prototype illustrating how the information should change on screen as a user progresses through a task. These solutions are developed by research. This research can take the form of competitor analysis, reading academic papers on human/computer interaction, or testing ideas on real users.

In the end, however you try to define it, information architecture boils down to consciously organizing the content and flow of a website or application, based on some principles that can be articulated, that have been derived through evidence gathering. At a micro level, this can mean deciding that products on a search page should be ordered by price rather than by name. On a larger scale it could be reorganizing the content on a site to support some clear tasks that users want to perform. On a strategic level, an information architect might get involved in determining the way that articles and metadata are placed into a content management system.

As pmNERDS go about making innovation into a science, the information architecture helps innovation teams discover relationships and values between information assets. The information architecture should provide support to the system of systems type of thinking that needs to take place in the correlation stage of making innovation a science.

Unlike the other two architectures, the Knowledge Management Architecture resides in the business unit as often as in IT. Knowledge Management Architecture is the application of an information and enterprise architecture to knowledge management. That is, using the skills for defining and designing categorized assets, and leveraging the correlations defined in the enterprise architecture to establish an environment conducive to managing knowledge.

Information architecture tends to focus on designing spaces for existing or predefined information assets. For example, one branch of information architecture focuses on findability, with little or no concern about how the information asset itself comes into being. In the knowledge architecture, the transition from data, into information assets, and then into knowledge is paramount.

Knowledge architecture, deals with potential information. So, rather than determining the best way to use existing content, the knowledge architect is designing "spaces" that encourage knowledge to be created, captured, and shared. In this respect, the actual content doesn't matter as much as the life cycle -- how and when it gets created and how best to get it to the right people quickly.

The knowledge architecture supports two types of tasks, Strategic and Operational. The knowledge architecture should provide focus and enable the accomplishment and measurement of business goals and objectives. There needs to be a concept of the knowledge life-cycle, and how new knowledge can be correlated to the accomplishment of the firm's goals. From an operational point of view, tasks such as knowledge identification, creation, acquisition, development and refinement, distribution, use, and preservation all fall within the realm of the knowledge architecture.

Some of the benefits of a knowledge architecture include capturing the rational for decisions, improved reusability of lessons learned and other experiences, an increase in quality decisions, minimized innovation and change risk, minimized design mistakes, ability to avoid dependency on key individuals, gain competitive advantage, encourage adoption of best-practices, improve efficiency of processes, and support case-based reasoning.

As pmNERDS go about making innovation a science, it's the knowledge architecture that provides the space for effect-cause-effect thinking.

Continue reading
707 Hits