What is the Right ERP Methodology to Use?

Solve this riddle: A project manager, system implementer, and a third-party developer each create a plan for implementing a new ERP system. Who has the best plan?

A. The project manager, who swears by the traditional waterfall methodology, delivers a 400-row Microsoft Project plan with dates and dependencies for each task.

B. The system implementer, who has never worked outside the Agile Methodology, is not familiar with Microsoft Project, but assigns dates for 3 iterations of development and testing for each key deliverable.

C. The 3rd party developer, who keeps up with annual SCRUM certifications, sets a daily schedule to discuss status updates and roadblocks with weekly milestones.

The answer: D. None of the above.

There is no single ERP implementation methodology that guarantees success. Each methodology— waterfall, Agile, and SCRUM­—has its strengths. However, each has deficiencies that arise in certain phases of implementation. Trenegy blends the best components of each method to successfully complete ERP projects on time and within budget.

The traditional waterfall methodology is a structured practice where progress is made in succession, only upon completion of the preceding phase.

The waterfall approach is the best methodology for identifying project dependencies, planning for necessary business decisions and establishing timelines for gathering requirements, all prior to configuration and development. It is overkill to develop an implementation plan that includes scheduling weekly data refreshes and granting user permissions before training, but when seemingly menial tasks are not accounted for up front, project deadlines will be delayed. In addition to proper planning, the waterfall methodology allows for consistent communication to executive teams on the status of the project.

The waterfall structure is rigid and involves significant upfront planning and requirements definition. Trenegy uses these components of the waterfall methodology during planning and design phases to ensure the implementation team has a clear vision for deliverables before development and testing begins.

Agile methodologies break projects down into tasks, which are completed in short iterations and delivered to stakeholders as packages of functionality. The deliverable evolves with each iteration of development, based on input from users.

Executing an Agile approach requires flexibility and the ability to deliver while operating under constantly changing requirements. Although little upfront planning is required, success is dependent on resource availability from project team members for testing new improvements as they are delivered.

Trenegy applies the flexibility of an Agile approach during construction and user acceptance testing, when there is difficulty prioritizing in a time crunch. Typically, the months leading up to a system go-live are hectic and more work remains than time or resources can keep up with. This method offers the flexibility to adjust scope to preserve budgets and timelines by delivering smaller pieces of functionality, knowing a future iteration for improvement will be necessary.

SCRUM is an even deeper form of the Agile Methodology, designed for rapid development and release updates in short, two- to four-week sprint cycles in order of stakeholder-defined priority.

SCRUM models are highly effective for rapid development and problem solving to address critical issues once the system is live. The first weeks of a system go-live can be overwhelming with busy support lines and a flood of help desk emails. This approach enables the project team to knock out blocks of open items by quickly identifying handfuls of the highest priority issues to fix during the next release cycle.

Trenegy practices the short release cycles and rapid issue resolution frameworks from the SCRUM Methodology during post go-live support. With this approach it is imperative to keep an up-to-date issues log to review during regularly scheduled sprint planning sessions. Reprioritizing improvements and sticking to defined release schedules is key.

There is no such thing as a one-size-fits-all methodology, but there is an optimal way to use each of the various implementation methods. Trenegy’s extensive ERP experience allows us to leverage the advantages of each to ensure successful go-live.

Why the Onboarding Process Matters and How to Make it Better.

Whether the oil and gas industry is booming or declining, organizations consistently shortchange the onboarding process. Many companies have abbreviated onboarding to a half day of skimming the employee handbook and receiving appropriate badge access.

This approach cheapens the new employee’s understanding of the company vision, compliance culture and performance expectations. It is critical for new hires to have immediate and meaningful exposure to the key components of a company’s culture, particularly regarding policies and controls.

With the right amount of planning and with limited but focused efforts, onboarding more than pays for itself in confident, loyal employees who understand the company’s culture and policies.

Why do it?


In highly regulated areas like SOX for financial reporting, compliance is non-negotiable. Public companies must ensure all new employees are aware of industry and company controls and are committed to abiding by defined policies. The financial investment in onboarding is preferable to receiving a significant deficiency or material weakness.

Accelerated Learning

Documented desk procedures will allow a new employee to move quickly up the learning curve. Well-written desk procedures boost a new employee’s productivity and will save experienced employees from spending significant time handholding.

Future Investment

Employees who have a clear understanding of job expectations can focus on delivering results rather than trying to learn job activities. An intentional and well-planned onboarding process can easily be repeated across functions with minor changes.

Key Components:

1. Desk procedures. A successful onboarding program includes detailed, current desk procedures. The procedural should include step-by-step explanations of the process the employee participates in. Process flows, roles and responsibilities, delegations of authority, controls and policies will all be included or referenced in well-written desk procedures.

2. System training. A new employee must understand how to perform his or her job tasks within the appropriate systems. How is an invoice entered? Where are particular contracts located? How are the required reports for month-end close run? What constitutes a hard error versus a soft warning, and what should an employee do in either case?

These questions should be clearly answered in system training documentation. Furthermore, a new hire’s supervisor, armed with clear training and defined training documentation, should be well-prepared to train staff in the systems.

3. Team introductions. New hires need a casual – but purposeful – introduction to the immediate team. This seems obvious, but many companies fail to encourage team leaders to build departmental camaraderie. Contrary to an isolated employee, an engaged team member makes a loyal employee.

4. Cross-functional understanding. A successful onboarding program includes cross-functional exposure. New employees must understand their roles within the immediate function and within the organization. Opportunities for cross-functional understanding come from lunch-and-learns, town hall meetings, and other cross-department sessions. A new hire should be made aware of these opportunities and encouraged to attend.

Onboarding is not an optional G&A expense, a mysterious formula or a waste of resources. With intentional planning and focused effort, onboarding is a simple, clean, repeatable process which wins the company enhanced controls compliance, increased return on employee investment, and loyal staff.

Making the Most of Your Controls Environment

Twin boys, one an optimist and the other a pessimist, awake Christmas morning with gifts in their bedrooms. The pessimist walks up to a pile of toys in his room and is irritated. “Do I have to read the instructions?” he wonders. “My friends will be jealous. The toys will break.” The optimist finds a pile of manure in his room and exclaims, “There has to be a pony in here somewhere!”

Public company executives often find themselves looking at the mounds of regulatory requirements created by Sarbanes Oxley and the PCAOB with disdain.

While mounds of manure are a reality, there is a pony!

A SOX 404 implementation program can be managed in such a way to gain organizational efficiencies and achieve more effective processes.

Eliminate Waste. During a controls and process mapping exercise, it is important to understand the purpose of all the steps in a process. Many fast-growing companies inherently have bad processes in place that worked for a small company.

A large oilfield services company spent an inordinate amount of time physically matching vendor invoices to checks for the Controller’s signature. This served the company well when they were small. As a larger public company, this was wasteful and did not serve a purpose. By implementing more efficient controls in the disbursement process, the company eliminated the paper matching process. Do not be afraid to look for ways to eliminate waste as a part of the SOX 404 implementation or review process.

Set Guiding Principles. The transition to the 2013 COSO framework implies a more robust and daunting control environment. Developing a set of guiding principles for the organization and each of the business functions links policies to strategy and sets the foundation for an effective control environment. Guiding principles capture intent, establish the tone from the top, and rally the organization toward implementing the right control activities.

A mid-sized exploration and production company used guiding principles as a motivation tool and a way to give each function a sense of purpose and identity in the new environment. The control, monitoring and risk management activities and policies were then tied into the guiding principles to ensure a common tone was established and integrated.

Integrate Risk Assessment and Planning. The mere sound of conducting a risk assessment wreaks drudgery. The risk assessment process should be integrated with the business planning process. One seamless, forward-looking process is more efficient than two separate processes.

A product of the business planning process is a financial budget for the upcoming year. Why not also make the risk assessment a product of the planning process? A public midstream company integrated the risk assessment with planning and budgeting and only added a week to the entire four-month planning and budgeting process.

Companies have no choice but to address the mounds of regulatory requirements to comply with SOX and SEC expectations. Why not use the compliance process to improve other processes in the organization?

Going Global: Overcoming Challenges in International ERP Implementations

An increasing number of today’s international companies recognize the benefits of connecting the entire organization through one accounting and operational platform. A global ERP system eases the pain of consolidated reporting, increases the speed at which the company communicates, provides innumerable efficiencies in terms of global master data, limits dual-data entry, and simplifies the intercompany transaction process.

However, with the many benefits of a global ERP system come the challenges inherent in launching an ERP system across borders, oceans, and cultures. The most common and significant challenges encountered during a global system implementation are outlined below.

1. A Global System Requires Global Support

The need for round-the-clock system support for offices overseas is often overlooked in a centralized company. Companies with centralized IT support underestimate the frustration employees across the world feel when waiting hours for assistance. If end users experience technical difficulties or are stumped by system functionality for hours at a time, productivity drops and the company loses money. Lack of support damages user acceptance and encourages “neglected” users to devise external, and often detrimental, work-arounds.

Companies launching a system overseas should be prepared to have on-site support in each regional office for two-three weeks prior to and post-go-live. Long-term, companies should offer at least one full-time system support expert in each time zone. System support experts can be new employees hired for the express role of system support, such as business analysts or system administrators. Alternately, existing employees can be identified as “superusers” during design and training. “Superusers” should be employees who demonstrate a strong understanding and comfort level with the new system and a knack for helping other users learn the system. At a minimum, there should be one system support expert in each hemisphere to ensure an increased overlap of business hours.

2. Don’t Bite Off More Than You Can Chew: Regional Rollout vs. Big Bang Theory

Many companies are overly eager to launch a new ERP system globally and are tempted to opt for the “big bang” approach to go-live, meaning all regions flip the ON switch at one time. This approach does offer benefits such as cost-savings, high levels of enthusiasm and momentum, streamlined processes and training schedules, and consolidated reporting efficiencies. However, companies should elect this approach with one key caveat: only go for “big bang” if you have the resources to support it.

Companies should only attempt the “big bang” launch if they have a large enough implementation team to put people on the ground in each region for go-live. In the vital weeks of training prior to launch and the critical weeks of operation post-launch, one of the most essential requirements is responsive, competent, and timely support. Without it, user adoption will suffer and the new system and its processes will struggle and eventually fail.

A company with a smaller implementation team is better suited to launch using a regional rollout model, which ensures one region is relatively self-sufficient before rolling out the next region. This phased approach usually means a longer timeline and increased implementation cost, but it mitigates the risk of launching everything at once and experiencing global failure because the implementation team’s attention and effort was spread too thin.

3. Be Aware of Cultural Differences and Leverage Them Wisely

One of the joys of working on international projects is making connections with people around the globe—appreciating similarities and learning cultural differences. Generally speaking, Westerners are generally less hesitant to express dissent, disagreement, or dissatisfaction. Companies should be aware of this tendency during the system design phase of the implementation and strongly encourage Eastern offices to contribute system requirements and design suggestions. An effective way to encourage this is to approach the system blueprinting as a collaborative effort instead of, “tell us everything that is wrong with the current system.”

End users in Eastern countries are often quicker to rely on training manuals and self-troubleshooting before reporting an issue. Conversely, end users in the West are inclined to reach out to system support immediately upon encountering an issue. Because of this dynamic, it is a best practice for companies to begin regional rollouts starting in the Eastern Hemisphere and progress west. The East’s propensity toward self-sufficiency means that they usually require less intensive post-go-live support, which will free up the implementation team to focus on the next regional launch.

In an international implementation, the increased size, scope, and complexity of the project increase the likelihood of complications. Trenegy has helped companies successfully implement ERP systems around the world.

7 Keys to ERP Implementation Success

System implementations are complex projects demanding much of an organization’s time, energy and resources. Companies desire projects of such magnitude to be done on time, one time, within budget and done well. As a consulting firm, Trenegy has witnessed companies go through system implementations with great success and great failure.

So, how does a company avoid becoming another failed system implementation statistic? Seven keys to implementation success are as follows:

1. Build Organizational Support

Organizations are often resistant to change, or at least hesitant. Create a groundswell of support for the new system by explaining to employees at each level why the change is beneficial. Executives can benefit from the support ERP systems provide to acquisition growth. Revenue accountants will have the opportunity to clean up data and streamline prior period adjustments. Operations will have access to timely production data and accurate lease operating statements.

Creation of a well-rounded implementation team is vital for organizational support and project success. The project team must have the right skill set and decision-making authority. Large-scale system implementations require a team of devoted project members who are committed to making the implementation a success. These members should have the right skills, a strong work ethic, and the ability to see the project to completion.

Subject Matter Experts (SMEs), such as the assistant controller or land manager, are also critical to change management and project success. SMEs are critical decision makers. They know where the business is going and can provide insight to ensure the system will meet future needs. Their knowledge of potential acquisitions and projected growth is invaluable. It is important for them to be aware as critical decisions are made throughout the project.

2. Understand Business Process Requirements

Automation applied to an inefficient operation will magnify the inefficiency.” –Bill Gates

In order to implement an effective system, an organization’s business process requirements must be clearly laid out, step by step. Initially, this requires asking the right questions, such as: What does the current process look like? How could it be improved for the future? What information is needed to quickly and successfully create an improved process? Specifics are important so processes can be revisited as little as possible. General ideas are subject to uncertainty, which leaves system implementers guessing.

This is where process flows come in handy and make understanding specific requirements easier. It is crucial to capture which steps occur before and after the process as well, because that heavily influences the process itself. Seek to understand what the process currently looks like and what changes need to be made to make it more efficient in the future.

3. Identify Critical Reporting Requirements

The importance of defining critical reporting requirements at the outset of an implementation cannot be overstated. Reporting is derived from the Flexible Business Structure— the backbone of data organization.

To create a system that pulls clean reports, an organization must predetermine the data hierarchy. Will budgeting occur by region or business unit? It is important to determine a standard method of booking certain costs. For example, management may decide that lease operating expenses (LOE) should be booked at the lowest level of detail (i.e. completion instead of well) to provide a greater level of accuracy in reporting.

Maintaining the integrity of the data model, reporting hierarchies and KPIs ensures that management reports will be consistent over time, giving decision makers valuable insight into performance trends.

At this stage, it’s important to take into consideration the trajectory of the business. If growth through acquisition is planned, understand that budgets and reporting views will need to accommodate additional divisions and support more transactional data.

4. Cleanse Data Prior to Conversion

The purpose of an ERP system is to provide accurate, timely and insightful reporting that helps managers and executives make better decisions. Clean data is needed to make the most efficient use of a system. Without clean master data, executives lack reporting confidence and are tossed back to square one: making business decisions with inaccurate information.

When critical master data comes from systems that are not integrated, major errors are prone to occur during data cleansing and validation. Merging master data requires experienced oversight and coordination–especially when different business functions own the systems being merged.

5. Practice, Practice, Practice

It is important to create training tools specifically designed for each organization. Standard technical documentation alone is not enough; it often leaves employees confused and frustrated. Tailoring training materials to the organization prepares employees to confidently acclimate to the new system.

Developing a training strategy that will facilitate learning and produce a change can be challenging. Training must be completed in a way that resonates with the audience and speaks to their learning style. What works for one person might not work for everyone.

Before the system is fully implemented, users should receive a broad overview of the system to become familiar with the interface. Then, prior to go-live, training sessions should be held specific to each function. Simulation training is more in-depth, as a system expert sits side-by-side with users to walk through daily processes.

However, it is unlikely that every possible scenario will be covered in training. Training should focus on critical elements and common scenarios. Training provides employees with the initial tools they will need to understand the system.

 6. Communicate Major Decisions

Too often, companies get into trouble by failing to document decisions, only to unnecessarily revisit them later. This ultimately results in rework and delays. Often, those affected by these decisions were not involved in the decision-making process.

Decisions should be clearly communicated and documented in a log maintained by the project manager. SharePoint is helpful for clearly recording when, why, and by whom decisions are made, as well as resulting task lists. These decisions should only be revisited when business changes require the project team to change course.

7. Motivate Your Team

System implementation is hard work! It can be easy to get tired and impatient, so keeping team members motivated is vital. Sitting together in an open room can keep teams energized and in constant communication. Urgent issues can be discussed immediately and when a problem arises, the entire team is aware of it. High cubicle walls and individual offices create physical and communication barriers.

There is value in ensuring project team members are able to get to know each other and relate on a personal level beyond a work environment. Knowing someone’s name and job description is one thing, but understanding their personality, learning style, and how they best relate to others lays the foundation for a more cohesive team. The most successful projects are completed by cohesive teams who communicate well, work hard to complete the tasks at hand, and share a common goal of seeing the project succeed.


Your ERP System is Live. Now What?

Congratulations! The ERP system you spent thousands of hours and millions of dollars on over the last twelve months is now live. If the proper implementation approach and project management methodology was applied, then this arduous task was completed on time and on budget.

So it’s smooth sailing from here, right? Unfortunately not.

There are a number of post-go-live challenges inherent in releasing a new ERP system, which will quickly derail the system’s launch if not addressed. The most common challenges are: project team burnout, limited end-user knowledge of the system, enforcing the data governance plan, and handling the myriad questions from end users.

Your organization can carry the successful implementation forward by following these steps:

1. Recognize and reward effort. The best employees from each department across the organization have spent nights and weekends building, testing and priming the system for go-live. The final weeks leading up to go-live can be the most challenging, and this same group will be heavily relied on to lead and support the organization during the first few months post-implementation.

Recognize the real, negative consequences of employee burnout and work to prevent its impact by:

  • Understanding the workload required to complete the tasks assigned to each individual.
  • Identifying supplemental resources early on.
  • Creating a clearly defined incentive plan before the project kicks off.
  • Rewarding each team member accordingly. Additional vacation days can be as valuable as cash or equity.

2. Keep training. User acceptance is a predictable challenge. Help users understand why and how the system operates to improve acceptance rates. Yes, there were a number of training sessions conducted before go-live, but those sessions alone will not suffice to prepare end users for day-to-day system tasks. More often than not, end users find training sessions held three to four weeks (a complete business process cycle) after go-live the most beneficial.

Post-go-live training sessions with participant-driven agendas are the most effective. This allows the trainer to focus on addressing the process steps and system functionality the user group is most concerned with. This approach will also increase attendance, as users will feel a sense of control over the utility of the training session.

3. Set up governance. Eight or nine months have likely passed since the process owners came together for design sessions and agreed to improve process efficiency and data quality through cross-functional collaboration. In reality, that cooperation will not be so easy to maintain once the system is live—a governance model for managing process changes must be in place.

However, the governance model should not be convoluted or overbearing. Create standard forms and workflows to approve proposed changes (e.g. new account, account structure change, new vendor, etc.) to help manage these requests. Ensure that proper security is applied and maintained to help eliminate rogue changes.

4. Create an issue resolution process. Regardless of how thorough the test plans or how diligent the testers, issues will arise post go-live. You must be prepared to manage and address them. The majority will be quick fixes, but a handful will impact closing the books or paying a vendor.

Establish a process to prioritize, resolve and communicate post go-live issues. Provide users with an easy way to submit issues and keep them in the loop as technical changes are made. Managing this well prevents users from working outside of the system or falling back into old routines.

Trenegy helps companies successfully manage ERP implementations all the way through go-live support. We help our clients get value of out their new system quickly and relatively painlessly. Read how to properly prepare an E&P company for implementation in our recent publication: E&P Company Systems: 4 ERP Implementation Land Mines to Avoid.

Improve Reporting Through the ERP: How to Make Better, Faster Decisions.

An ERP system is designed to connect data from all major functional areas and improve an organization’s reporting capabilities. The goal is faster, better decision making by senior management, aided by a current and accurate picture of the organization’s performance.

To achieve this goal, an organization must first decide what information it needs out of the system. Because many configuration parameters cannot be changed after system integration has begun, it is important to identify critical reporting requirements at the outset of an ERP implementation.

While there is no one-size-fits-all reporting model, there are a few considerations that will make or break the usefulness of your final reports:

1. Use the increased level of detail available with a new system. Understand the new capabilities of your ERP system and develop a reporting hierarchy that takes advantage of more precise revenue and expense classifications.

With a new ERP, many companies are able to increase expense categories from three to 15, allowing for a much more granular view of profitability. This allows an E&P company to parse out smaller expense classifications, like how much money is spent on vehicles, at each well site.

Similarly, legacy systems often limit the definitions of cost centers to units, wells and leases. A new system can expand these categorizations, giving management a comprehensive view of balance sheet activity. A completion can be recorded as such, rather than as a well. A unit can be recorded as a legal land unit instead of a grouping of wells used for accruals.

2. Set up the reporting hierarchy to support budgeting. The hierarchy in which you book and report your revenue, production and expenses should be consistent with the level you want to budget. Even if budgets are managed outside of the primary ERP system, actuals and basis for comparison will always be housed in the ERP.

Operations and accounting constantly struggle over reporting needs. Operations may want to view billable versus unbillable LOE, or operated versus non-operated status, at a field or well level, but accounting wants to see information at a higher, aggregated level in the hierarchy. With careful planning, the hierarchy can be set up to accommodate operations’ reporting needs as well as internal and external financial reporting within the same structure.

3. Consider the company’s long-term goals and growth trajectory. Ensure the ERP is set up to support growth by cleansing data before go-live. Clean master data sets a solid foundation that can sustain the burden of additional data in the event of an acquisition.

Consider the amount of history needed for reporting. Unused or excess accounts in the Chart of Accounts (COA), properties that have been sold, or wells that have been plugged and abandoned for more than five years should not be set up in the new system.

While thinking about the future may seem like a no-brainer, companies often become so consumed with supporting current requirements that future considerations and long-term growth plans are not taken into consideration. A certain level of reporting may not be needed today, but will it be needed in the future?

Companies invest in ERP systems to improve efficiency and profitability. Developing a reporting strategy prior to implementation will ensure maximum benefit and desired outputs are achieved. Trenegy helps companies implement a variety of ERP systems and develop reporting strategy that fits business requirements and supports long-term strategic goals.

Building a Resilient IT Strategy, or Just Fancy Binders?

IT executives are constantly faced with the challenge of delivering a high level of service and value to their customers while managing a tight IT budget. In most organiza­tions, the cost of IT has increased more (as a percent of sales) over the past ten years than any other administrative cost. Our research has shown, in many organizations, it takes five revenue dollars to cover every dollar spent on IT.

Among business leaders, the IT function remains the most mis­understood component of a corpora­tion’s cost structure. Most executives struggle with the CIO’s suggestions to spend millions on enig­matic items. Providing a framework for the CIO to manage and communicate technol­ogy directions, costs, benefits and stan­dards to the business is a necessary step for improving the organization’s ability to execute business strategies using IT.

To address the IT delivery model for a business, virtually all major corpora­tions and institutions have developed some level of an IT strategic plan. These strategic plans are intended to guide the IT organization’s allocation of resources and align IT with the strategies of the business. But if most major enterprises have developed IT strategies, then why are these companies continuing to struggle with managing and understanding IT costs? Why are the IT stra­tegic plans sitting on a shelf collecting dust in the CIO’s office next to a few other consulting studies on the benefits of SOA or upgrading to Windows Vista?

Strategies that Fail

The following strategies fail to meet expectations because ERP systems are not all things to all people. The resulting environments do not provide reporting and analytics, or the business process improvement capabilities promised. Because of this, the legacy IT strategy is thrown out the window along with millions of wasted dollars.

ERP Centric. Our experience has shown that most legacy IT strategies are not sustainable, nor do they address the real business issues. Instead they focus on addressing point-in-time business needs. It is common for a company to suppose a new, multimillion dollar ERP system will solve technology issues. These ERP Centric strategies are developed because it is easy to see how an ERP platform could become the rallying cry for IT to improve business results. The problem lies in the assumption that the current application environment cannot support the business strategies.

Implement ERP. ERP rarely touches specialized applications that are critical and unique to the business operations. This focus in implementing ERP often immediately eliminates alternate ways to meet strategic business needs from a technical perspective.

Jumping to ERP. Other options such as ease of use, business intelligence, upgrading current applications or improving application integration capabilities get lost in the shuffle and are not always addressed in legacy IT strategy. Jumping to ERP forces an answer and sometimes allows other viable options to fall through the cracks. In addition, large projects usu­ally move forward without any par­ticular agreement on implementation principles, change management, quantifiable success measurement or joint buy-in from operations, sales, human resources and finance.

Strategies that Work

How can today’s corporations and institutions develop an IT strategy that is sustainable, comprehensive, realistic, and part of the everyday job of the IT organization? Virtually every IT strategy begins with understanding the company’s overall business strategies, processes and pri­orities. Determining the IT implications of these business strategies then becomes the foundation. Whether corporate strate­gies lead to administrative cost reduc­tions, the need for scalability, or the need for faster IT response, the strategies need to be linked to actionable technology principles and standards.

An IT strategy focused on technology principles and standards is the key. IT principles and standards can become longer-lasting strategies for an organization. Technology initiatives alone (whether strategic or not) are not lasting and can be quickly rejected once the business case is exposed or the business changes direction.

Avoid wasted effort by establishing guiding principles that define how the IT organization should execute key processes like planning, standards management, technology deployment, support, maintenance and operations.

Once guiding principles are defined, the IT strategy becomes clear. The IT strategy can be reviewed regularly as a critical part of the planning proc­ess to provide unified direction for IT and enable a realistic budget. Each year prior to budgeting, the IT leadership team should spend time with the business, formally reviewing IT strategies, making rec­ommenda­tions for improvement and updating action plans and principles as required. If certain initia­tives are not approved in the budget, then IT strategy adjustments may be necessary. This process should drive the IT budget for the coming year and provide a balance of costs and service levels expected by the business.

Remember: Whichever IT principles, strategies and initiatives an organization decides to accept, an optimal balance between managing costs and improving value will rarely be achieved without a resilient IT strategic planning process in place.

The 6 Most Important Provisions in a Statement of Work

All parties involved in a system implementation must agree on a statement of work (SOW) before the project can begin. However, as with any lengthy contract full of complicated clauses and legal jargon, it is easy to lose sight of key terms. Omission of these important provisions can cause budget problems later in the project.

SOWs from Systems Integrators (SIs) are especially complex given the technical nature of the work. Keep an eye out for these six key points in a statement of work to avoid eventual dispute or delay:

Service Level Agreement. A detailed list of expectations for the new system should be plainly stated within the agreement. Projected report run times, data storage capacity, and system outputs (reports, metadata and spending metrics) depict a clear vision of the system’s ultimate functionality. This level of description gives all parties a tangible idea of what “finished” means.

Team Member Performance. An agreement needs to be established around the project management model. Predetermined governance ensures that service issues have an established mode of resolution. For instance, in the case that an SI’s team is not performing as expected, can either party request team member changes? There should be a structured method of replacing a team member who is not performing. Document these details within the agreement, and the project will run smoothly with the best resources available.

Hours Billed. An important clarification, and one that is easily overlooked, is the criteria for time that can be billed back to the company. It is far easier to address this issue at the outset of a project. Travel time and expenses are typically included, but it’s smart to get specific parameters for the definition of travel time. For example, are hours spent in a car or on a plane billable? Ask for an estimate of expected working hours per week for each phase of the project. Each of these items, no matter how minor, will affect the project budget.

License Details. The systems integrator should include a section detailing licensing agreements. Terms and cost of licensing should be outlined and agreed upon up front. Additional costs, like yearly maintenance and fees for future upgrades, should also be listed. Without these items, ambiguity of ownership can cause problems when an organization needs to make further system changes or updates.

Variance Agreement. Over time, changes in the business environment might necessitate alterations to the project plan. Be sure that all parties are updated on project revisions by explicitly requiring within the SOW that all changes be documented. If additional work is requested, a new work order needs to be created, signed and added to the original agreement.

Project scope. Another critical stipulation to be included in the SOW is the scope of the project. This section should list all of the vendor’s responsibilities and tasks, such as implementation/migration, testing, training and support. This list will help determine when new work orders are needed. The project scope also sets expectations for the level of support the company will provide the vendor. For example, the company needs to be clear about how many employees will work on the project and which subject matter experts can be consulted for major decisions.

An SOW without these points can leave room for disputes on payment amounts, expectations and other project details. By developing a detailed SOW, everyone involved in the project can focus on the critical path to completion. Trenegy helps companies successfully prepare for system implementation by ensuring vendor agreements are clear and comprehensive.