Strategic planning
As director of IT Business and Financial Systems at Arkansas Electric Cooperative Corporation, Barbara Harris has a lot on her plate. Among other things, AECC, the generation and transmission electric utilities for the rural distribution cooperatives in the state of Arkansas, owns, maintains and operates power plants and generation and transmission facilities. Harris is responsible for critical financial elements of the running the company. She doesn’t have time, money or human resources to waste, yet she’s no stranger to pandemonium wrought by simple-sounding IT changes and upgrades.
“The biggest challenge we have is adequately scoping these projects,” Harris said. “People just tend to minimalize what’s necessary to get the project done” in terms of the budget, manpower, storage, how long integration, configuration and implementation will take, and more.
Harris wants to accurately gauge what’s involved from the start. “I would rather know up front that it’s going to take two more people and 18 months” than to be told it’s a six-month project that can be done with existing staff and have costs underestimated, she explained.
Hamway sympathizes. “The more definition that is documented prior to any work, the better,” she advised. “Missed items, or inaccurate scope, are often a result of poor planning and not going through a thorough discovery phase.” While it’s tempting to some customers to skip the discovery phase and get straight to work on resolution, it’s not worth it, Hamway added, because that often leads to missing scenarios and pitfalls.
Unfortunately it’s not always so unintentional, according to Lee Paul, CEO of Estero, Florida,-based Surround Technologies, LLC. Some vendors undercut the scope or leave things out in order to get the job, he said, explaining that “if (the project) is too big, they’ll scare the customer away.” But “it’s criminal to do that;” it’s not fair to the customer, Paul said. “We strive very hard not to do that. We never want to come in over budget” unless it’s due to the customer choosing to “grow to the size of the tank” with cash reserved for additional features. Paul urges vendors to be honest and realistic with customers. “You want to be in a position to say, ‘Hey, we’ve got extra budget, let’s do this …’ not, ‘Hey, we’re running out of budget, let’s cut this out …,’” he explained.
“The way we manage our projects,” Paul continued, “is to do a good scope,” during which three things are identified: “your knowns, your known unknowns, and your unknown unknowns” that get discovered during the project – “and those are the scary ones,” he said.
The knowns are easy. “You scope those out … and we have what we call strategic reserve time in all of our projects,” understanding that to deliver the best solution “we should build in a little extra time for what we can’t predict or know,” he said. Strategic reserve time works at two levels: the estimate, whereby the development team can manage estimate variations, and at project feature implementation, where “we know that there’s going to be feature functionality that we didn’t think of, that will be really useful to the project,” he explained. “We want to put room in the project for that. We don’t want to keep going back to the customer, or going back to the manager and the development team,” proposing necessary changes and their new budgetary requirements. “Out-of-scope items are big, major items,” Paul said. It’s best to account for them up front and manage them with strategic reserve time.
For this, Surround Technologies uses very defined scope templates to ensure that nothing gets missed, Paul noted. These include any known unknowns that were not analyzed or included in the estimate. Then there are the unknown knowns, which Paul jokingly described as “the fun ones,” those that the client knew about and forgot to mention during the discovery process. They’re usually small and aptly handled with strategic reserve time, but anything major is considered out-of-scope.
Communication
“During the past several years working with ERP upgrades, integration projects and process automation, we have found that accurate scope definition is key,” Hamway agreed. “As big proponents of application lifecycle management, or ALM, we have learned that wherever we can reduce risk and increase productivity, we need to take advantage of the available discovery and collaboration tools. With these tools in place, we can optimize vendor-customer communication and concentrate on what is important – the client’s success.”
But “there are always so many hidden pieces in any project you start to do,” Harris said. “I guess my biggest fear then is: What’s the thing we didn’t scope out? Where’s the gotcha that’s going to come back and really bite us? We try our best to avoid any of those gotchas, and to plan ahead and ask lots of good questions, and most of the time we do a pretty good job of it,” but there have been projects involving something totally new, “(hence) some questions we just didn’t know to ask,” she said.
It happens in every project, “no matter how much due diligence we do,” Harris continued. “It’s not necessarily for lack of trying to catch all the gotchas,” she explained; “sometimes there’s just no way you could have known what they would have been.” Other times it happens despite a thorough needs assessment and accurate projection “because folks overpromise,” which can result in over-expenditure of time, money and other resources, she said.
How can an IT-solutions company help alleviate Harris’ fears?
“It would help me if they would anticipate those problem areas” and potential challenges and be realistic about the functionality she’s trying to gain, she said. Don’t promise a product will deliver more than it can, and “tell me upfront what it’s going to cost to do it and if I need to make additional purchases, or if we know it’s going to take more time with implementation or I need more services, (etc.),” she said. “I want to know up front.”
That’s the nature of “scope creep,” said Chris Hird, owner/director at Shield Advanced Solutions Ltd. in Toronto, Ontario, Canada. Internally, a team can agree that they can accomplish something, “and then we start to do it, and then it takes a lot longer and causes a lot more issues than we thought it was going to take because it’s so complex,” Hird said. “And you’re dealing with so many variables in terms of interfaces and (more), so what works in one scenario might not work in another,” he explained. “That’s always going to be a problem.”
But even in estimating the duration and work involved from a project outline, miscommunication is not uncommon, Hird noted. “The problem is that you’ll go somewhere … and everything’s working as we need it to, and they say, ‘Yeah, but I need it to do (something else).’” If that wasn’t in the original scope, it becomes a question of how long will it take to fix, because the client needs it, he said.
“Now, all of a sudden, the cost overruns are going to be huge because most of what you’ve designed and built is based on the original request,” Hird continued. “To add something in afterward generally takes a lot longer than building it from scratch.” What many customers don’t understand is that “when you structure the design for an application, it tends to be segmented,” he explained. When a client wants something changed, (s)he doesn’t realize that change in one area affects every other area. “You tend to work the best you can to give the clients what they want,” he said, but neither the client nor the developer can accurately gauge what changes will impact what or how long it will take to get it right. So “if you get the design right up front, obviously it’s going to be a lot easier because you know exactly what you’re going to be doing, and everything is created around that; all the code is created around that design.” This is why it’s so important to effectively communicate visions, goals, needs and expectations as accurately as possible from the start.
Miscommunication sometimes boils down simply to a technical language barrier between the developers/programmers and the clients. “It’s very difficult,” Hird admitted, “because no matter how many times you ask the question, you get the answer that the customers think you want to hear. The problem is that your understanding of what they want, and the actual reality, is generally very different.” Misunderstandings happen, he said. “These things are very complex in nature. And so everything that you do, you do with a best will,” he affirmed, “but because they don’t have your skills to develop it, and you can’t extract enough information out of them to develop how they want it,” there’s a communication gap.
Hamway’s company regularly conducts ERP upgrades and consulting on IBM i integration projects, and she’s found that much in terms of success ultimately rides on the vendor-customer relationship — something Hamway Software Solutions has revered since its inception, she said.
“The relationship between the vendor and the customer is very important,” Hamway asserted. “The better you know your customers, the less you rely on them to tell you what they don’t know.”
Vendors should take time to get to know the customers and their environments, she advised. “The more knowledge and understanding you have of a customer and his or her methods, the easier it is to apply our past experience and ask the right questions — perhaps framed specifically for the customer’s own perspective or level of understanding — in order to elicit the most accurate, insightful and relevant answers,” she explained. As with any good relationship, try to put yourself in the other’s shoes, Hamway suggests. “Understand that if the project or software is new to the customer, he or she won’t know what to ask, because it is new,” she said. “It is the job of the vendor to get past that and uncover other areas of the customer’s environment that may impact the scope of the project.” And customers, “don’t be afraid to ask the vendors questions – let them know what you think the biggest risks or concerns of the project are. That way the vendor can address those concerns,” she urged.
“I agree that we developers and vendors, from the outside, cannot see everything, and a scenario can be missed,” Hamway conceded, “but we must do our due diligence and get the most information possible. We include in our documents a set of assumptions. In this section we list scenarios that we may have encountered with other customers and we state that we assume to be true or not. This list may jog something in the customer’s memory and prompt him to ask a question,” she explained. “This will then allow us to discuss that topic in-depth and tweak the scope document accordingly.”
From a well-thought-out, well-defined scope document, planning for project resources, time, and impact on the customer’s staff evolve more naturally and thoroughly, Hamway said. Then, when the nearly inevitable scope creep or missed scenario is found, “we always discuss with the customer their options,” she noted. “The options can be to make something a phase-two issue, estimate the amount of time needed to add it to the current scope, or it could be that the change is simply not worth the cost.”
Business relationships are personal relationships to Hamway, especially in terms of care, support and reliability. She recommends that customers “choose a vendor that you can build a relationship with, as those are the vendors who are going to care to give you the best service, best estimates and best support,” she opined. For example, “when we’re called in to a project, we help with that,” she noted, “but we also educate the organization’s staff so they can support the changes after we leave. Then down the road, if something comes up, they know they can call us back.” Also, “utilize all available resources to gain information on the software or project you are considering implementing – user groups, vendor references, articles, etc.,” she said.
Hamway also believes it’s important that IBM i professionals build relationships with fellow IBM i users, an integral motivator to her launching MAGiC. “Within such a network, you cultivate a support system of your own,” she said, adding, “One common example: You can learn from other businesses that may have encountered issues that you’re encountering and have found ways to resolve them.” Furthermore, she noted, the more empowered, knowledgeable, supported and equipped that IBM i user-group members are, the better they can serve their own customers as software developers, vendors and IBM i professionals.
Paul urges software developers and vendors to set realistic expectations, clearly define and communicate them, and identify the problems they’re trying to solve. “Don’t just think of building software or building a feature,” he said; realize that “you want to solve a problem with everything you’re building.”
Time management
Tim Knight, IT manager at Yupo Corporation America in Chesapeake, Virginia, wishes he’d done a few things differently the last time he took on an internal project.
“Several times over the last 18 months I had to pause goals because my ‘official’ job responsibilities had to take precedence over the project,” he recalled. “If you are in IT and managing the project, this can be especially difficult,” he said.
“Everybody has to deal with that; he’s not alone,” Paul said. “It’s very normal, and no one has the perfect answer. You gotta’ face it head-on and figure it out.”
Hird concurs. “The only way you can get through it is to prioritize,” he said. “Prioritize based on what you think is a priority and what your clients think is a priority,” he advises. “All you can do is do your best and hope that your clients see that you’re doing your best.”
Paul recommends hiring a company to either manage the change project or temporarily provide professional services for the day-to-day department tasks so that regular staff can focus on the change project. Surround Technologies provides such solutions, but the point is to help the customer manage his time, he said.
“Understand that the more you (delay the project), the worse it gets,” Paul urged. It’s called legacy drag, he noted, but he prefers “technical debt,” a debt of technology that drags a company down and holds it back; like a bankruptcy of sorts.
“The more you don’t do those projects,” Paul explained, “the worse your technical debt can potentially get because you’re taking more shortcuts. So it’s pay me now or pay me later. And the more you build up that technical debt, the harder it’ll be later and the less you’re getting on the return on that investment you have to (make).” Eventually, some companies end up throwing it all away and turning to some multi-million-dollar provider for a total overhaul, he said. To avoid such drastic measure, “you have to make the project the top priority.”
Consider breaking down a big project into smaller phases that are achievable and bring quicker return, Paul said. “And follow the 80:20 rule: Do the 20 percent of the work that’ll get you 80 percent of the return.”
The bottom line is that “something has to give somewhere,” Paul concluded, “and it shouldn’t be the new project that’s going to help you with that problem in the future.”
To accomplish this, Knight recommends that people “shed as many current responsibilities as possible, as far in advance as possible, before declaring the project is off and running.”
In addition, “ensure that you have mapped out every department’s responsibilities for the project and that there is complete buy-in from upper management,” Knight advised. “Memories can get very short when pressure is on and suddenly a gaping hole in the plan is discovered. Losing management during the transition phase can result in you owning that department’s issues, so be aware of this and move quickly to find a resource if this happens.”
Knight also recommends finding trustworthy, reliable consultants. “Try to establish a relationship with them that allows them to be open and honest with you,” he said. “Their experience (working with) other companies can really help you if you are willing to acknowledge your own plan’s shortcomings and adapt to their advice. Most of the time you are doing something for the first, and possibly last, time while this may be the 20th for them,” he noted. “Use their victories and failures to your benefit,” Knight said. “If I had spent more time up front dealing with (these) issues, I would have reduced a substantial amount of stress on me and everyone involved in the project.”
Harris doesn’t consider herself a project manager, per se, even though her job sometimes requires that she be one. “It’s still kind of a challenge to me,” she admitted, and even though project management is necessary and important, “it doesn’t feel like you’re actually getting work done,” she said. “So finding the templates and methodology that work for an organization is pretty important.”
Other challenging elements of a major change can include company culture shock, duration of total changeover, and necessary training, Harris noted. But on the other side of a successful project, it’s worth the effort, she said. Whether it’s a matter of meeting compliance requirements or of getting up to speed with communication, access and overall workflow, successful change boosts efficiencies, proficiencies and overall standing company-wide.
Hamway Software Solutions is a Virginia-based software-development and IT company with 25 years of experience designing IBM i solutions. Specializing in ERP Implementations, Integration and Process Automation. Learn more: https://hamwayss.com//
Arkansas Electric Cooperative Corporation is the generation and transmission electric utilities for the rural distribution cooperatives in the state of Arkansas. Learn more: https://www.aecc.com
Surround Technologies, LLC, based in Florida, aims to transform software developers into “Software Superheroes” by providing software-development and -modernization tools, custom technology solutions and consulting services to help them build better and faster than ever before. Learn more: http://www.surroundtech.com/
Shield Advanced Solutions an IBM Business Partner, has been providing products and services for the IBM i and its processors AS/400, i5 and System i for more than 20 years. Learn more: https://shieldadvanced.com/
Yupo Corporation is a world-leading engineer and manufacturer of synthetic paper and other creative materials for print marketing, packaging, promotional items and more. Learn more: http://yupousa.com/
Author Nora Firestone is a professional writer/reporter, website designer and book publisher’s acquisitions editor in Virginia Beach, Virginia. Learn more: http://norafirestone.com
