Planview AdaptiveWork is a powerful platform. With custom fields, custom objects, workflow rules, custom actions, and global CSS/JavaScript, there's almost no limit to how far you can tailor it to fit your organization. And that's exactly where the trouble starts.
Over the years, I've seen many well-intentioned configuration efforts gradually cross the line from "tailored to our needs" to "suboptimal and unnecessarily complex." If you are responsible for an AdaptiveWork implementation or ongoing administration, this post is for you.
When Customization Becomes Over-Configuration
Every customization starts with a reasonable request. "Can we add a field to track X?" "Can we automate this approval?" "Can we create a custom object for vendor management?" Individually, these are smart moves. But without a clear strategy, they accumulate — and the platform starts working against you instead of for you.
Here are the warning signs I see most often:
Lack of a dedicated Product Owner
Sometimes the biggest configuration problems aren't technical — they're governance problems. Some customers use AdaptiveWork exactly how it was intended to be used: as the organization's project management information system, enabling standardization and PMO-level reporting. But other customers have a wide range of user groups with completely different business needs who want to leverage AdaptiveWork's configurability to create feature sets for their unique processes. Or they have different project management workstreams that each want AdaptiveWork to be configured specifically for their desired methodologies and business practices without considering the impact to performance and ongoing maintenance. Configurability is a great strength of AdaptiveWork, but you need a dedicated product owner to evaluate and prioritize the configuration wish list with assistance from a knowledgeable AdaptiveWork technical consultant who can help identify the trade-offs and potential pitfalls that occur when everyone gets everything they ask for.
Workflow rules that trigger other workflow rules
What starts as a simple automation becomes a chain reaction. One field update triggers a rule, which updates another field, which triggers two more rules. Before long, saving a single record kicks off a cascade that's difficult to predict and even harder to troubleshoot. I've worked with organizations where no one on the current team could explain why certain fields were changing — the original configurator had moved on, and the logic was buried across dozens of interdependent rules.
Multiple custom objects and custom links to support extraneous processes
Every organization has business processes that are ancillary but related to project management. For example, an RFI (Request for Information) process or a billing process. Or they might have a process completely unrelated to project management, but they want to leverage AdaptiveWork's configurability to create a custom solution to meet the need. Depending on the configurations involved, this can either be a clever way of leveraging the tool, or it can mean AdaptiveWork's core value is compromised by unnecessary complexity that compromises performance and adds maintenance overhead.
Fields and business rules that no longer apply
It's surprisingly common to find dozens of custom fields and/or business rules that were created for a specific initiative, never cleaned up, and continue to add clutter and overhead. I have seen evaluation criteria across multiple rules to account for scenarios that will never happen because they were part of an abandoned business process. Yet the rule must continually check for that deprecated scenario.
A Simple Framework for Smarter Configuration
Before building anything custom, I ask three questions:
1. Can the platform do this natively?
AdaptiveWork's out-of-the-box capabilities are extensive. Before creating a custom object or workflow, make sure you've explored whether a native feature — or a simpler configuration of one — already exists.
2. Who will maintain this after I'm gone?
This is the question that gets skipped most often. If the answer is "whoever replaces me," that's not a plan. Every custom configuration should be documented and simple enough that a competent admin can understand it without archaeology.
3. What's the cost of this customization over time?
A configuration may take five minutes to create, but if it adds a few seconds to every page load or business rule execution, those costs compound quickly. Not to mention the hit to user experience. And it could take hours to troubleshoot two years from now when it conflicts with something new. Factor in the long-term cost, not just the build effort.
The Goal: Configured, Not Complicated
The best AdaptiveWork environments I've worked in share a common trait — they're thoughtfully configured, not maximally configured. They use custom fields and workflow rules where they add clear value. They document everything. And they resist the urge to build a custom solution for every request that comes in.
If your AdaptiveWork instance has grown unwieldy — or if you're about to embark on a new implementation and want to get it right from the start — I'd love to help. A configuration audit can identify what's adding value, what's creating risk, and where you can simplify without losing functionality.