Clarity

Hi PPM practitioners! Unless we’ve been hiding under a rock lately, we all know that businesses across the globe are in various stages of digital transformation, fueled in part by the need for greater agility. We also know that designing to deliver solution outcomes that support business outcomes is an important part of this transformation.

Many organizations are struggling to make the paradigm shift from a focus on implementations to one on outcomes and insights. To meet a business requirement, which may not be relevant six months from now, we often over-engineer the solution (instead of asking why and what value it will bring) or we lose sight of the importance of balancing other components like solution maintainability, adaptability, and sustainability.

What is Over-Engineering?

Simply put… making a solution more complicated than it needs to be, delivering capabilities that will never get used, or designing for too far in the future.

What are the Consequences?

When working with customers to implement CA PPM and conducting PPM health or maturity checks, I frequently run into the issue of over-engineered solutions. There are many consequences, but in this blog, I’ll focus on three common ones. Let me emphasize that I’m not implying that the architecture examples below are wrong—just that you need to be sure you’re doing them for the right reasons.

1. Reduced Process Agility

Over-engineered solutions often reduce process agility by making the solution cumbersome to work with and/or adding a lot of non-value work to the user’s day-to-day business process—which generally leads to low adoption. And if the solution isn’t utilized as intended, it certainly can’t provide value to the organization and support the important business outcomes and insights for which they were targeted.

Some common examples of this include:

1. Creating dozens of custom attributes (most of which will never be used in real practice). This often happens when there is a lack of PPM process standardization, and each department wants its own flavor of the same field. The team creates complex partitioning and/or builds dynamic lookups when process standardization may have been the right business decision in the long run. It also frequently happens when transitioning off a legacy system to CA PPM. In this case, the team often tries to replicate every field in the original system without considering its current relevance and value (or whether CA PPM already has an equivalent field). Another common occurrence is when the team tries to automate most of the project document artifacts when a simple attachment attribute or link would suffice. Bottom line, if the field isn’t consistently reported on somewhere, it probably isn’t needed. 
    
   
2. Over-loading screen white space—e.g., configuring project/other object properties pages with so many sections and fields that users must infinitely scroll (and don’t populate half the fields). This often happens when lots of custom attributes are defined (per above) or when the team tries to make the project properties page a one-stop shop for everything. CA PPM provides collapsible sections to help simplify page views, but the key is to keep the pages clean—with relevant information that’s simple and easy to understand.
   
   
3. Creating so many custom sub-pages that users forget where information is stored (and justly complain that it takes too many clicks to find something). CA PPM sub-pages are extremely valuable in segmenting information based on authorization to access and/or categorizing information by topic without overloading pages with too many sections/fields. Balance between simple navigation, page content relevance and ease of use is key.
   
   
4. Notification spam, generating so many user notifications that they lose context and value. This often happens when the solution is designed to alert users when an event happens/action is needed/something is due. Alerts are great, but if users will naturally be informed in their routine interaction with the system, they may not want their Outlook inbox filled with dozens of messages every day. Alerts can be good when time-sensitive action needs to be taken or there is a significant time lapse between reviews. Again, balance is key.
   
   
5. Process gridlock often happens when the team develops too many tightly controlled workflows for project governance processes, such as project initiation, approval and stage gating. CA PPM workflows handle this capability well, but the solution is often designed with too many steps and fails to give the project manager a way to handle exceptions or start over when something doesn’t go as planned. PMs get frustrated and look for ways around the system.

2. Reduced Organizational and/or Operational Agility

A solution may be over-engineered if it delivers lots of bells and whistles but fails to deliver significant outcomes aligned to organizational strategic objectives. In this case, organizational and/or operational agility may be reduced; someone likely forgot to ask “Why are we doing this?” and focused on delivering capabilities that have nothing to do with driving value to support business priorities. As in #1, this will generally result in low adoption or the product being shelved.

Here’s a not-so-obvious example:

Let’s assume an organization’s top business priority is to restore cost competitiveness, so IT is charged with reducing operational costs by $10 million in the current FY and an additional $20 million in next FY. IT implements CA PPM to provide the financial transparency to properly select, prioritize, and manage investments. The project team quickly focuses on deploying project and schedule management and time tracking. A very common approach… however, it really doesn’t help achieve the target outcome in the current FY. The customer needed a more portfolio-decision centric solution that would enable it to quickly target investments with the best potential to meet the cost reduction goal and apply the appropriate funding to those investments. Schedule management and time tracking were important, but implementation of out-of-the-box portfolio management, demand management, and project management with simple budgeting would have been a good starting point for Release 1 to allow the basic intake, review, and prioritization of investments via the portfolio waterline and dashboards. A roadmap targeted to align PPM capabilities by priority/release to support the organization’s objectives would have been valuable.

3. Reduced Technical Agility

To use a popular phrase, “just because you can, doesn’t mean you should.” Deploying lots of complex and/or low-value customizations can also make it very difficult to maintain the product and adapt to new technology or business changes without a lot of intervention, which ultimately leads to low sustainability, which usually leads to product sitting on the shelf, contributing little to no value, and/or doing the proverbial restart.

Let’s say an on-premise, heavily customized customer only scheduled an upgrade release every two years due to the length of time it typically took them to remediate and test new releases. The customer could benefit from many of the new features, but doesn’t have the capacity or budget to stay current, or at least -2. Had the solution more closely followed CA’s modification policy when the customizations were designed, it would have been much simpler to deploy upgrades with less remediation needed on a regular and more timely cadence. (See my recent blog on Technical Debt.)

How Do We Prevent Over-Engineering?

The best way to prevent over-engineering your PPM solution is by keeping crystal-clear focus on your core business drivers for implementing PPM and the target outcomes and insights you want to achieve. Every business requirement should be closely examined to ensure it fully aligns to one or more business drivers (the why), and that the solution design for that requirement delivers an output (the what) that makes a positive (and measurable) contribution toward achieving the target business outcomes and insights (the value). Whether an agile, waterfall, or hybrid delivery approach is taken, CA Services is highly focused on ensuring that business outcomes are properly identified, prioritized, and mapped to the requirements/user stories that will make up the delivered solution. CA Services and certified partners follow PPM good practices when designing your solution, leveraging decades of experience and hundreds of customer implementations. Our focus is on your success and making sure you not only get your solution implemented properly, but taking the extra step to ensure you get full functionality out of your investment in CA PPM.

Readers interested in more detail around CA PPM can check out DocOps. I encourage you to participate in the best-in-class CA Communities site, where you have access to your peers, events and support. You can also reach out to CA Services for information about CA PPM and individualized business outcome references and analysis. Feel free to post in the comments section of this blog or contact me directly via email and Twitter @kdobsonppm.