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 Resource Management, discussing resources used to increase competitive advantage

A Capacity Planner: How Many Can You Lift?

“If I am a capacity planner, then I am always looking for optimal functionality, but really, what do I do?”


Who is a capacity planner? A capacity planner gathers performance data and measures the output to determine optimal fit within the production scheduling. A person in this position is normally at the business unit level, but there are enterprise level capacity planners that look at the whole organization, such as Resource Forecasters or Resource Estimators. A business unit capacity planner may be called a Performance Manager or a Performance Engineer among other titles, but who are they really? Every job is more than just a title.

In previous posts, I have determined the best way to describe a project manager to a child is to classify them as a superhero, like Batman. So, if a project manager is Batman, then a capacity planner is a lot like Alfred, Batman’s butler. Don’t be mistaken, Alfred was way more than Batman’s routine servant. He pretty much raised him. If Bruce was being foolish, then Alfred efficiently reprimanded him. In the background, he never stopped guiding him in the right direction. This is a capacity planner.

A capacity planner can go by many different names, but at the end of the day, the goals are still the same. As a capacity planner, you are here to understand the priorities, the resources available, the true cash flow, as well as the intricacies of the time frame. Alfred understood Batman’s true priorities. Batman wanted to destroy all his foes and save every single maiden, but it took Alfred to continuously remind him that he is only one man. As one man, he only has so much capacity. This inevitably led to the introduction of Robin and later Batgirl. Batman increased his capacity to match the increasing demand.

It might seem trivial to say that the capacity planner needs to understand priority, the cash flow, the time frame and everything else, but it is more complex than you think. It is a balance of continuously fixing the past, adjusting the present actions, and planning for future growth. Planning for growth could entail adding more physical locations, adding personnel, or capital to raise for any given expansion. This plan is always a factor in determining how many transformational/major change projects you can accomplish in a year. How many projects can you really afford given the resources as well as the budget? Sure, you could run yourself and your team down, but as Alfred understood, you still must eat and sleep, even if you're a superhero. In capacity planning, you can’t invoke only major change if you have requests for maintenance/utility or compliance mandate projects.

Your business unit and organization needs a continuous spectrum of projects. If you can do three transformational projects given your organizational constraints than you would need to sufficiently space them across the next few quarters. In between these major projects, you always have a spot for last minute projects or required maintenance projects. A capacity planner is working to design an optimal project schedule by weighing the risk, priority, cash flow, and organizational capacity.

Capacity planning involves looking at what resources are being utilized and making sure these are being allocated correctly for optimal functionality. Managers with this mission are leading their Batmans’ in the direction that means success and growth of the organization by considering the priority, resource availability, and the fluctuating cash flow within a given time frame. Alfred is the only real father figure Batman has in his life. The one force that Bruce Wayne knows will always have his back in any situation. He is the man behind the man. He is the capacity planner.

Continue reading
71 Hits

Systems Thinking

“If I considered all the business functions impacting project success holistically, then project performance would be more consistent and manageable, but there are just too many factors to consider, and management would be ineffective due to analysis paralysis.”

Projects are at the root of Integrated PM. Change is at the root of projects, and it follows that change is at the root of Integrated PM. Central to Systems Thinking is the performance management of this change. Systems Thinking is applied successfully when these three situations below exist.

First, there is someone who is dissatisfied with the current situation. This someone would like to achieve one or several goals, or maintain current threatened levels of achievement using a change the project is supposed to produce.

Second, the way of invoking that change is not obvious. The problem situation is complex. The interested someone may not have enough information about the situation to know or discover all the consequences of decision choices, or to be able to evaluate the performance of these options in terms of their goals, principle purpose, or strategic intent.

Third, the interactions between various elements and projects have a degree of complexity that the limited computational capacity of the human mind cannot evaluate in the details necessary to make an informed decision.

The typical environment where projects exist are systems. What is a system? For now, a system is a collection of things such as tasks, projects, programs, and portfolios that relate to each other in specific ways, i.e. that are organized and follow specific rules of interaction. Collectively, they have a given purpose, i.e. they aim to achieve or produce outcomes that none of the parts can do by themselves.

We can recognize or view something as a system for our own purposes. This is an important insight, in the real-world systems do not exist or create themselves spontaneously, readymade for us to discover. No, Systems are human inventions. We choose to view projects as a system to better manage projects and improve performance.

If we are to deal effectively with the complexity of projects and decision making within our system environment, we need a new way of thinking. This new way of thinking evolved about 1940 and could be labeled ‘systems thinking’. This system thinking has been proven successful within the context of projects. System thinking is used in decision processes which help decision makers explore portfolios of projects in much of their complexity without having to drill down into the trees of the forest.

System thinking is used to find a ‘good’ or ‘best’ compromise solution, and is used frequently to give answers to important ‘what if’ questions, such as “how is the ‘best’ solution affected by significant changes in various cost factors?” or “What is the effect of uncertainty in a critical resource scheduling?”

Integrated PM is the collection of practices leveraging systems thinking to better manage projects holistically within an organization. You’ll wonder how you survived without it. In truth, you probably weren’t surviving, you just didn’t know it.

Download this free E-book- Integrated PM: Applied System's Thinking with Portfolios, Programs and Projects

Continue reading
199 Hits

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
476 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