3 Ways to Ensure Your New Product’s Business Value

By Tom Yang, Changepoint Sales Engineer

Cha-Ching! To a Project Manager that’s the sound of your organization committing to a new product – knowing that now that the money has been spent it’s time for you to get things in place to support the investment. As with most large business purchases, but especially software, it’s essential you build a solid rollout plan to avoid or quickly address unforeseen obstacles. I know this from firsthand experience as I work side by side with our customers to implement our Changepoint and Daptiv PPM solutions, which in turn are then utilized to facilitate the rollout of many other products.  Time and again I’ve witnessed how a Project Manager’s ability to lay the foundation for a new product has been crucial in determining its level of attainable business value. To ensure you’re building a solid structure you’ll want to start with a product implementation plan focused on defining your goals, providing the transparency necessary to keep everyone on the same page and ensuring you’re prepared for any problems that are bound to arise along the way. Sounds simple enough, so here’s how you can get started:

Set SMART Goals

Aligning SMART goals with pre-stated business objectives is the best way to meet major milestones during a product rollout without confusion or major setbacks. Making goals SMART requires them to be: specific, measurable, attainable, realistic and timely. Therefore, when outlining the organization’s objectives the new product goals should go beyond the vague, “roll out budgeting to the PMO” to the more defined, “enable the PMO to track budgets on a monthly basis for all IT Projects and summarize quarterly.”

Ensuring business objectives are also clearly defined through these SMART goals eliminates any confusion over what your organization is trying to achieve or how they plan to get there. In addition, if an objective isn’t met on time it’s possible to determine exactly where the failure occurred and course correct. For example, perhaps a goal your team was targeting on a monthly basis was too difficult to achieve, but moving it to quarterly made it more realistic.

Tying these goals to timed milestones is key since it allows all teams and levels of management to hold each other accountable. If these milestones are missed (beyond the standard margins of 5%-10%) you’ll know it’s time for either the goals or the timeline to be re-evaluated to account for any delays. One tip to minimize confusion, but keep goals measurable, is to start with time estimates (I.e., It will take two weeks for each module) as opposed to setting actual dates (Module 1 will run from 1/1 – 1/15.). This way if you have to make a shift it’s much simpler for teams to adjust those time frames and you stand less of a chance of mixing up dates.

Ensure Transparency

While implementing SMART goals goes a long way in providing transparency around the product implementation mission, you can’t stop there.  It’s crucial that you also work to provide a similar level of clarity to your teams around roles. You can do this in part by clearly identifying the main vendor point of contact for the product purchase, their specific responsibilities and a backup or manager. Ensuring transparency at this stage is key, because the primary contact during the product sales cycle will likely not be the same person assisting your business with all of its deployment needs. Since it is rare to work with the same people on both pre-sales and post-sales efforts you should request a knowledge transfer call that includes all those individuals and your team to make sure everyone is aware of your organization’s needs.

It’s also important to be clear on what responsibilities fall to the product vendor, as well as the scenarios during which it’s likely that they will need to bring in additional resources or send issues that arise to another team, to limit surprises and setbacks. If you fail to define these areas to your teams before rolling out a product it can leave them frustrated as each issue is investigated and resolved slowing down the deployment progress. Here’s an example I’ve experienced:

A vendor I worked with offered and even touted their ability to create “customized grips” for certain products. However, when asked to add them during production it was revealed that the process was actually carried out by a foreign subsidiary, which added three weeks to turnaround time. While in theory, a typical product deployment shouldn’t require extensive additional resources, in those rare cases the vendor should be able to explain them beforehand and you should remember to ask. This helps to limit surprises, and at times keeps the vendor honest. In this example, if my team had been clear on what the immediate vendor could provide as well as the process for getting other needs met we would’ve been able to account for the project delay.

Process Your Problems

Since every problem is unique, the best and often only way to prepare for them is to establish a process that lays out exactly how they should be addressed and who will handle them when they arise. Being prepared with a process for managing problems is critical to keeping a product rollout on track. For example, something as simple as the best method of communication needs to be identified and stated early on. This basic knowledge allows teams to know whether they should email or call to effectively escalate an issue. This process should also dictate when an issue in the product rollout has reached the threshold of being a full blown problem or is actually just a delay that can be accounted for by shifting milestones. Another tip for ensuring you’re prepared for anything is to ask the vendor to walk you through some of the common obstacles they’ve seen in similar deployments, which should give you some insight into what to look out for and the kinds of solutions your product vendor is likely to provide.

Spending the time upfront building out these three elements will go a long way in making your implementation journey less bumpy, which increases the likelihood of a product’s success and ultimately the value it provides to your business.

Have you saved your own company from a product rollout disaster? Share your tips to limit sweat and tears on LinkedIn, Facebook or Twitter.


Project Honeymoon

Sometimes projects don’t quite go as you expect them to.

My wife and I recently returned from our honeymoon in Namibia.  The country is truly an amazing place and I cannot recommend visiting enough.  Otherworldly scenery and fantastic wildlife viewing went hand and hand, day after day.  It was the trip of a lifetime but at times it was a different trip than we planned.

We thought we had our itinerary all planned out when we arrived in Windhoek, the capital city.  An old/nonexistent booking system caused some confusion at the lodge we planned on spending our first night.  Lucky for the two of us, we had rented a 4×4 with camping gear.  What’s the use of a 4×4 if you can’t get it dirty?  We changed our plans, shifting our entire itinerary and headed in the opposite direction and into the Waterberg Plateau, along hundreds of kilometers of sand and gravel roads.

In the initial stage of a project just one small hiccup can alter the whole direction of a project.  Sometimes that’s a bad thing, sometimes it’s not.

Camping earlier and for more nights than we planned changed the entire trip for us.  We decided we didn’t need a lodge at any point of the trip and kept exploring the national parks from a more humble viewpoint.  In places where predators lurked, we stayed in fenced in camp grounds to keep us safe but in smaller areas without lions we had a much more open experience.  Chasing monkeys away and waking up to warthogs in your camp are memories we wouldn’t have had in a lodge, no matter how luxurious a lodge that might have been.

Sometimes when travelling, being flexible makes the whole experience better; on occasion, the same is true for a project.  One small early change can point your project in a new direction.  Sometimes a new direction is indeed for the better.

Happy Valentine’s Day.


Healthier Project Resource Capacity Planning and Forecasting

Executing best practice principles is an often overlooked requirement to accurately forecast an organization’s resources on a continual basis. Whether it’s a Professional Services Firm using Professional Services Automation (PSA) or an internal IT group using a system for Project Portfolio Management (PPM) the same principles can be applied for successful Resource Capacity Planning Forecasting. When creating such a forecast, first distinguish between the “target” (what an organization wants to achieve) and the “forecast” (what the reports say). After distinguishing between the two outputs build the forecast and target with the following characteristics.

The Characteristics of Healthy Forecasting

  • Actionable: Excessive effort to apply too much data can affect the logical decision making ability of executives who may need to make hiring and firing decisions based on the information provided. Bad decisions can result from including data or extra “noise” that is not related to revenue or utilization.
  • Aligned: The treatment of the forecast and target should be the same in the way they are created. This means their formats should be identical, and the numbers and data input should be consistently applied.
  • On Time: If the forecast is one that shows “over a cliff” and unforeseen problems, the information needs to flow up the chain of command quickly.
  • Cost Considered: If the forecast is within range and the output is a known and accepted target, then there is no need to spend additional time on it when the data does not require a decision.
  • Reliable: If the forecasting process has yielded pressure points that require an executive decision then all scenarios should be shown when the forecast is presented, including data-driven remedial action recommendations.

Resource Capacity Planning Forecasting is a continual activity that applies modest amounts of knowledge in a disciplined and reliable way. Resource Managers who adopt the characteristics above when forecasting for improvement efforts can help executives drive their organizations toward desired targets. When done correctly and consistently this process also has the potential to positively affect internal perspectives, practices, politics and processes that support growth and security of a business.

By Alan Crean, Changepoint’s Subject Matter Expert in PSA, PPM & Resource Management within IT Shared Services Organizations

Finding the Real Problems Before Jumping on the Training Bandwagon – Part 2

As discussed yesterday, in technology-based change many companies identify additional training as the answer to spur adoption but often miss the real underlying problem. In today’s blog we’ll discuss two potential root causes for lack of adoption as well as solutions.

First—sponsorship. Is the functional executive regularly demonstrating support of the well-informed use of the technology, or the timely and effective participation within the processes? Is he/she verbally expressing that support in forums or in one-to-one conversations? Is the leader using the technology or requesting information or reports that require others to properly query the tool? These are forms of demonstrated support—not just sending out a corporate-speak email that declares the launch date and the business case, then perceived by the audience as ‘everyone better get on board or else’. Effective demonstrations of support must be repeated for the long haul and be genuinely part of the mantra of that leader and ultimately those who choose to follow. Without demonstrated support or direction, individuals can easily find other priorities or simply not give the technology-enabled process the simple attention to detail it deserves. “I’m really busy today… I’ll get back to that tomorrow.”

In his book Good to Great, Jim Collins describes how successful companies typically exemplify the culture and behavior of its leaders. This purposely demonstrated support bridges the wide gap from the ivory tower to real ownership in a personal, authentic way. Suddenly, team members might think “Wow, she’s really serious about this—I need to get my ducks in a row.”

What do you mean by ‘discipline’?

So we picked on the executives a bit—now for everyone else. Discipline falls to everybody within an organization. And unfortunately, it may also take a lot of time and hard work to improve. I believe whatever discipline exists (our definition here can be rigor, consistency, or commitment to a process or way of working) comes from the deep rooted culture over time. If people witness others behaving or acting in a certain way, it’s more likely that they will adopt those behaviors.

But this discipline opportunity can tie right back to good sponsorship. It’s another chance for leaders to express the desired focus, outcomes and behaviors within the environment in question. How might end users act when they hear an executive say to them, “We are making multi-million dollar decisions every quarter on new product development priorities based on the timeliness and accuracy of the data you manage in this tool”? My hunch is most would heed the beckoned call.

But let’s not throw learning needs out the window. The point of this piece is not that training or learning won’t help, or are not the root cause of low adoption and poor performance, but that training is an easy scapegoat when things are going awry. Unfortunately, the act of learning is not sexy or a quick fix—much less easy. And even when training is the right choice, it can still be poorly planned, developed or delivered. Frankly, it’s sometimes easier to lay blame where many are involved rather than on specific leaders or behaviors… with the simple notion of ‘people are not doing this right—let’s do more training.’

But there’s a better first step. Asking people close to the pain points for their input is not only a good starting point for unearthing real problems, but it’s also a very positive way to mine useful data. At the very same time something else profound can begin to happen—those people feel they are being heard and their opinion might actually matter. If people feel empowered and part of the solution, ownership and commitment usually begin to rise. Even if learning is found to be at least some part of a solution people will be much more receptive if they were included in the discovery process from the start.

Join the conversation: Follow / Like / Connect

To Train or Not to Train Is the Question – Part 1

“We need training!” These three words are likely stated in repeated glory as much as any often-used phrase in business cultures. I’ve heard it proclaimed from individuals including administrative assistants, functional subject matter experts, HR generalists, managers and executives—even training professionals!

In fact, when I hear those words I’m reminded of one of my least-liked graduate school professors. While I wasn’t a fan of his approach or attitude, I must credit him for providing our class with the single rebuttal I would use time and time again—“Is training the real need?” Try using it the next time you hear the aforementioned declaration of blame. And while watching the other person’s facial expression change to pondering or thwarted, you’ll have a few seconds to counter again with meaningful suggestions to help discover what’s really affecting productivity. Here are just a few …

  • Have we asked the people closest to the process for their input?
  • Do we truly know that a significant percentage of users are lacking the necessary knowledge or skills?
  • Do we even know where exactly the root cause problem lies?

Your transmission is not really broken…

Consider automobile repair as an analogy. Have you had those few, yet joyous, occasions where your trusted technician delivered the outstanding news that your car would only need a $79 repair when you expected it to be hundreds, or maybe thousands of dollars? The reason that happened is based on a few simple truths—a trusted resource looking in the right places with the right diagnostic tools to find the actual problem; not disassembling the entire transmission and replacing all the inner parts when an inexpensive sensor was the actual culprit.

In technology-based change user adoption of the tool of choice or related processes is a broad and potentially expensive symptom of what might be a more straightforward problem. Declaring that users aren’t well-trained infers that a lack of knowledge or skills is the direct and only contributor to low adoption. But is that the real root cause of the adoption gap? For our automobile analogy, a major undertaking of training would equate to the extensive transmission repair. Many companies decide quickly that training is the problem, reassign resources or hire in new ones, build elaborate strategies and plans, require a large portion of the work force to attend training on multiple topics, spending tens or hundreds of thousands of dollars…only not to solve the underlying problem causing the low adoption.

In tomorrow’s blog we’ll discuss two potential underlying problems and solutions to increase adoption without making ‘lack of training’ the scapegoat.

Join the conversation: Follow / Like / Connect

Written by: A.J. Holley, Director of Change Management and Learning 

A.J. Holley joined Changepoint to lead the development of a new Organizational Change Management solution to help customers manage the human element of change–a core challenge to any project or business transformation. Holley has over 15 years of experience leading organizational development and change management initiatives, and shares best practices and valuable strategies for project managers to apply to make communication a more calculated and strategic tool for project management success across a business.​