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.


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.​

The Ghost of Projects Past

January is often a time of reflection; as we begin a new year, it forces us to look at what we achieved in the previous one against what we set out to do, and create plans for the year ahead. For many, this will come with a sense of good achievements, but for others, things have unfortunately not gone so well. 2014 was littered with examples of highly visible project failures…disasters in some cases, costing companies and tax payers millions, the repercussions of which will not only have a knock-on effect for 2015, but potentially years to come. A few high profile examples come to mind:

  • The SNCF train fail: In May, French railway operator, SNCF (Société Nationale des Chemins de fer Français) ordered 2,000 new trains that were too large for many of the stations they are due to serve. This failure in the verification process cost the operator in the region of $57 million, as well as making headlines worldwide – only not the kind you want. It demonstrates the huge potential impact that one oversight can have, not just in terms of embarrassment to the organization and the cost of replacement, but in the ripple effect it has across the business and massive reallocation of resources required to remedy the mistake.
  • Major Projects Authority Annual Report: In May, the UK government watchdog that oversees IT projects, the Major Project authority, released a report warning that several major IT projects in the UK are at risk of failure and need urgent action’. According to the report, four major IT projects were given a red light rating, which is the rating used by the MPA use to describe projects they consider to be unachievable. These included:  the Ministry of Justice’s (MoJ) Shared Services Program (forecasted costs for which have risen from $88.6 million to $191 million); two Ministry of Defense (MoD) projects, including the $7.5 billion Defense Core Network Services program, which will replace the MoD’s computers, telephones, video conferencing equipment and networks; and The $1.5 billion Watchkeeper intelligence project.  These failures and delays have largely been caused by a misunderstanding of the original requirements, underestimation of the resources needed, and miscalculations around the technical specifications.
  • Obamacare: Last but not least, over the course of 2014 we have seen numerous stories relating to the controversial Obamacare project, with multiple IT failures and rising costs. The computerized sign-up system is said to have quadrupled in cost from $56 million to more than $209 million between September 2011 and February 2014, while costs for the electronic backroom for verifying applicants’ information are said to have jumped from $30 million to almost $85 million. Added to this, a contract for fixes to the website also grew from $91 million in January to $175 million as of July. Overall, according to a Bloomberg report, the Obamacare website costs have exceeded $2 billion. Again, this is largely due to mismanagement.

These headline costs are pretty eye-watering, yet the real-world costs are even worse. Many organizations simply don’t have visibility to the tangible and opportunity costs of project failures as a whole: while they may calculate the immediate cost in terms of lost revenue and productivity, the longer term ripple effect across other business units and projects is rarely accounted for or easily calculable. This domino effect means that as one project fails or over-runs, human capital and other resources are then diverted, meaning other projects are then delayed or halted…thus further extending the ripple.

This is why it is so important to have a centralized, real-time view of the financial health of all of your projects at the portfolio level, as they are running. By looking at projects at a portfolio level, businesses can better foresee, estimate and isolate the fall-out from individual project failures. Visibility is critical to success; organizations have to be in control in order to be agile and make adjustments on the fly.