Skip navigation
All Places > Clarity PPM > Blog > Authors Paul Obirek

Clarity PPM

2 Posts authored by: Paul Obirek Employee

It was about 15 years ago when I first heard the term GEMO, the acronym for “good enough; move on.” I was working for a PMO at the time, and GEMO became our mantra.

 

The head of our PMO—I’ll call her Jane —was a strong and confident leader in a tough healthcare environment in Canada. Since we had very aggressive goals, Jane needed her team, a self-professed bunch of perfectionists, to focus on our most important tasks. She knew that, left to our own druthers, we could get lost in analysis paralysis. 

 

Jane also understood the PMO’s stakeholders: physicians—also perfectionists—for whom patient care was Job 1.

Our work was about business processes—not so much about patient care. For that reason, Jane knew that while our work had to be good enough to achieve our goals, it did not need to be perfect.

 

I’ve never forgotten that lesson and, over the years, I’ve applied it at many of my customers.

 

How does this all apply to Core CA PPM deployments? That’s where GEMO comes in very handy: If you understand that good enough gets you far enough, you know that CA PPM will give you proof of value in four to six weeks. 

 

What’s the trick? Really, there is no trick—you focus on the CA PPM core benefits you’re trying to achieve and break them into smaller, incremental—and thus achievable—goals. That’s working in an agile fashion—incrementally building on the implementation and configuration you initially deploy.

 

Does this mean you need to have a highly complex initial deployment? No! Let’s say you start your CA PPM deployment with a basic configuration: You load resources, some canned security groups, a very simple OBS, and basic use cases to get you up and running quickly. Working closely with CA Services, you’ll identify your basic needs and get the minimum basic configuration up and running, all in two to four weeks. Proof of value then follows quickly.   

 

With CA’s classic UX, this process required a fair amount of coaching and hands-on training for end users. But with CA PPM’s new UX, end-user training is much simpler. The intuitive new task board and simplified design allow end users to learn CA PPM, leverage its power and start being productive almost from day one. Typically, the biggest challenge is cleansing your source data from your old systems. 

 

With CA PPM’s new UX, organizations reach the “good enough” point with the initial deployment. While it won’t accomplish 100% of your goals out of the gate, it will let you take a big first step in the right direction. Your organization gets the value of a strong PPM system, users engage and work in the tool, and you learn how you can tweak your processes to better incorporate CA PPM in managing your organization’s work.

 

After you reach the “good enough” point and realize initial value, you can “move on” to the next incremental steps that will achieve your long-term CA PPM goals at almost any cadence you choose. As you work with CA Services on the initial deployment, the consultant will help you understand the possibilities for succeeding increments.

 

That’s the beauty of GEMO: Your initial implementation doesn’t have to be perfect; it just has to be good enough. You focus on a quick and lean configuration for your initial deployment, and follow up with a clear path for your next increment. Then you rinse and repeat.

 

Talk to one of our sales folks to learn more about our Core PPM deployment offering.  It’s your best option for a quick time to value PPM solution.

CA PPM Core Implementation for 50-100 users

CA PPM Insights Blog: Steve Robinson on how easy data loading leads to faster use for more value.

Paul Obirek

It’s about the work…

Posted by Paul Obirek Employee Nov 9, 2017

Going to CA World? Join my Modern Business Management session Thursday, 16 Nov 2:30pm in the Agile Management Agility Zone/Tech Talk area.

Modern business management is about understanding, tracking, and managing the entire ecosystem of work in your organization. It doesn’t matter if the work is based in Scrum, Kanban, Six Sigma, Prince 2, PMBOK, or any other approach to delivery. This is much easier to say than do. Things can go off the rails for any number of reasons. One of the lessons we’ve learned at CA is, arguably, the most obvious and one of the hardest to overcome. It’s the words we use to talk about work.

When work is viewed and talked about differently by different delivery methods across an organization confusion and misunderstanding easily creeps into discussions. The most obvious example we see, we see it almost daily now, is how traditional methods view and speak about work compared to agile modes of work. That’s not to say the same challenges don’t exist when talking about methods based on bodies of knowledge like Prince 2 and PMBOK. Those challenges also exist. But, because the language between traditional methods is very similar, they don’t often surface as quickly or as visibly. These differences in how words are used to describe work can result in:

  • Unique interpretations of data between and within BUs.
  • Data with similar labels but different interpretations being consolidated inappropriately.
  • Explosion of the number of reports in the business to accommodate unique interpretations.
  • Sub-optimized business decisions due to differing interpretations.

Based on experience, I would suggest the differences between agile and traditional ways of work makes it easier to identify disconnects in how people talk about work within an organization. It also makes it easier to start to solve sooner when compared to differences between two or more traditional methods. This is because the stark differences in how agile talks about work compared to more traditional ways shines a much brighter spotlight on those differences. When looking at the differences between two different traditional approaches to work, like Prince 2 and PMBOK, the spotlight on differences often happens very late in the game and is not nearly as bright. By the time these differences between traditional methods are addressed damage is already done and decisions are being made with sub-optimal information.

The differences in how words are used to describe delivery makes it a challenge to have a holistic look at an enterprise portfolio. Different approaches to delivery of work can and do use similar language to describe similar concepts and ideas. In two traditional delivery approaches a ‘risk’ for you may not be the same as a ‘risk’ for me. Contrasted with a traditional view of teams (resources) against an agile view of teams (people) and it’s easy to see how easy the contrast is between newer agile and more traditional ways of working.

The obvious question is: How do you overcome this important difference in how people use words? While not yet a full blown agilest myself, I find the answer in some of the key elements of the Agile Manifesto:

  • Individuals & Interactions
  • Working Software
  • Customer Collaboration
  • Responding to Change

 

By valuing individuals and interactions people become more receptive to both hearing and accepting changes in how they use words. For example, I have been making a conscious effort to stop referring to people as “resources”.  This is a direct result of my interactions with my colleagues in the Agile Central practice.  As a result, I no longer think of people as numbers in a resource capacity and demand planning tab in CA PPM. To me, a team is no longer an abstract concept but is a collaboration of people with names and faces.

I equate the “working software” component of the manifesto to represent any work. In other words, I expand that definition to the context of business agility.  The concept of working software is broadened to include all work related to achieving the business objectives. More specifically, any work needing to be done in a timely and quality fashion to achieve a specific business goal.  In an ideal world: all work happening in an organization. So, in trying to change the language in your organization the emphasis needs to be on finding common language to describe work.  Understanding and communicating effectively about how work is identified, defined, allocated, and tracked is only possible with a common business vocabulary for your organization.  But, in adjusting your thinking to this approach you do need to be careful.  As my friend and colleague Gene Mrozinski pointed out to me, a true agilist may not find this perspective very resonant.  Without being clear the context of the conversation is expanding beyond software to include business agility you may introduce unintended resistance to this kind of conversation.

Customer collaboration is critical to overcoming these differences in words. Customer can represent both internal and external parties.  When addressing this semantic challenge all parties must be willing to collaborate to a common end.  The kind of collaboration needed helps define a positive working relationships between groups and individuals to achieve common goals.  Without the willingness to collaborate to find a solution to this semantic problem the problem of ships crossing in the night will simply continue to perpetuate.

Lastly, responding to change is critical for success in any well-run organization. My favourite phrase learned from my colleagues in the Agile Central practice is “sense and respond.” To me, that statement says it all.  The ability to sense and respond to change is the nirvana of business agility.  In order for anyone to do this we need to be willing to accept information and then respond to that information in a positive way.  This means that, when addressing the challenge of bringing different methodologies to the table, all parties need to let go of dogma to find a common business language.  Letting go of dogma can be one of the most difficult things an individual does.  An important part of being able to let go of a worldview is being presented with new information challenging the existing status quo.  This means being open and able to sense when something legitimately counters a particular view you might hold dear.  Once you’ve identified a challenge you can then respond with an open mind and a positive outcome as a goal.

Keeping these key elements in mind, an organization needs to work towards defining a meta-model to act as a translation layer between the different ways an organization works. This meta-model makes sure all parts of the organizations are communicating in a common business language while still retaining the strengths and uniqueness of each approach to delivering on work.  There are no common meta-models in the market place one could consider to be “one-size-fits-all.”  Therefore, each organization needs to look closely at their own specific needs to define a meta-model supporting its own unique needs. This is no easy task.

In the end, it is a lot of hard work to:

  • Overcome methodological inertia
  • Adjust individual points of view
  • Embrace compromise around definitions

In CA Services, we’re concentrating on helping to avoid these kinds of challenges at our customers. We’ve put together our Modern Business Management team. As PPM’s VP of Product Management Kurt Steinle likes to say “We’re tying to help our customer eliminate the work about work.” Our team consists of people from Agile Central Services and PPM Services practices to collaborate with our customers to find new ways of addressing these types of challenges. Ultimately, a business needs to know what’s going on across the whole enterprise. That means having the ability to speak the same business language anywhere in the organization. Using the CA ecosystem of tools, we want to help our customers overcome this and other barriers preventing them from achieving maximum success in their organizations.