10 Critical Components for an ERP Project Plan

We know there are hundreds of elements in an ERP project that can run the project off the cliff.  How many people would admit to having crashed a project and brought it back from the dead.  These projects are easy to lose control of and have the project fail.  I tried to keep the number of best practices to just 10 but couldn’t do it without leaving out some of the good ones.  In the final analysis, there were more than 10 Dos but wanted to stay focused on what was meant to be in front of the project team.  There are no guarantees even if each of the recommendations are followed to the tee that the project won’t go off the rails, but the project will surely have significant less risk involved in the overall roll out of the system. 

The top issues that have been seen across industries are: 

1) The complete lack of an executable project plan.  Even when the SOW indicates it is part of the System Integrator's deliverables, some of the SIs are resistant in creating one, or at best creates a shell that is not used in actual execution of the project. Many things happen or more accurately, don’t happen when there isn't a plan. First, there is no way to know where the project is relative to each milestone, so it is absolutely impossible to explain to senior management if the project is on time or budget.  Secondly, the dependencies that can be built into the plan aren’t visible to the project team, so deadlines are missed due to others not completing the work in the right sequence, hence the go live date is always being adjusted out further in the year.  Also, the roles and responsibilities and who is responsible to perform which activities is also vague because the names and ownership is not attached to an actively managed task.  Finally, The lack of a plan associated with such complex projects, leads to more change orders that add time to the project and cost to the budget to get what was promised in the SOW.  It costs more and takes a lot more time to do. 

2)    Another severe project issue is the Business Justification and Executive buy-in for the project.  Without the leadership of the company supporting the project, the necessary resources and commitment from other managers and peers in the organization can withhold valuable people who are needed to complete the different and difficult tasks aligned in the project plan.  The senior management of the company is responsible for funding and approving key decisions that have a direct impact on the outcome of the effort.  The culture of the company comes into check here, without commitment, the project can and usually becomes an IT effort that the business can later not adopt, or continue using the older legacy applications that have been in place forever.  

3)    Definition of Scope and Requirements are the bread and butter of ERP.  Without clear direction, even the early configuration of the instance cannot be completed without significant assumptions.  Gartner has developed a PACE layering approach that now focuses on the differentiator and innovation within the business requirements.  During the workshops, the Subject Matter Expert or SME and business representative are asked not what everybody else does, but what makes the company unique.  Finding the key differences between one company and the market, allows the company to focus on what is important rather than worry about the non-value added capabilities of a software package.  Some of the non-value areas might be paying the bills or running payroll.  Every company is different in which features and functions are foundational and which add competitive advantage to the company.  Gartner’s Pace Layering and defining the 3 levels of features helps narrow what areas need to have resources attached to the deliverables and which might be outsourced. This stratification of the functions sets up a clearer prioritization of work to deliver what is most important to the company.

4)    The Definition of Key Deliverables and Milestones is imperative in developing the overall project plan.  Knowing what the key deliverables are is the first step to knowing who might be responsible for them and when they fit into the project execution sequence.  Some of the key milestones might be the approval of the project, funding or charter to start the project.  In some companies, there is a formal capital request process that must be completed to ensure the financial return is included in the project deliverables.  Just a quick note on that, the interesting thing is most companies never go back and check the actual payback or loss after the project has been completed.  The other milestones might be specific deliverables in the scoping and design of the application, the build phase is a big deliverable and of course, the completion of testing is a huge milestone for any ERP Project.  Knowing the major efforts enables the outline of the project plan to be completed.  Now all you need are the dates and resources to make it complete.  It should be that simple right?

5)    Planning for the Project is by far one of the most important tasks that can be done during the preparation of the launch.  Once the System Integrator is onboard, it might be too late for the plan to have much chance to be a true reflection of what the project needs to complete and when. Most of the projects I am asked to assess, and in the end, rescue, lack any resemblance of a plan.  Face it; writing a project plan is hard to do. Each ERP project includes a different application footprint, and the companies have a different hardware and workflow configuration and user base, plans have to be custom written for each project.  Let’s make it simple.  As much work as they might present there are only five things that have to be described at the beginning of the project. 

§  The Milestone which might be a deliverable
§  The Tasks that support the Milestone
§  When the Deliverable needs to be done and how long it might take
§  Who is going to do it
§  Which tasks depend on other tasks being done before another

Obviously there is a tremendous amount of work to describe the project when it is a Global, multi-company effort.  The trick in getting the plan together is starting at the beginning and knowing you have a structure that can be expanded to include the other sections.  Most project plans are broken into 5 sections, 1) Analyze, 2) Plan, 3) Design and 4) Build. 

In the Analyze phase is really the discovery phase, what is the scope of the project, which order should the software be deployed, are there regional or localizations necessary to include in the deployment, and what does the implementation team look like with the definition of the core team and partners such as System Integrators or other 3^rd party vendors.

The Planning phase is just that, developing the plan and getting the proper input to know what, when and who will have a part in the delivery. 

Once the project is planned, next comes Design.  Actually thinking about the company requirements and how the software will represent the configuration of the different processes within the company. This section also includes the Architecture solution and infrastructure necessary to bring the system online.  There will be database design, instance design, programming design, security, and identity or Separation of Duties, or SOD design.

The final step is building what has been designed.  This step also includes the deployment and go live processes.  There is testing embedded in the processes as well.  Remember, each one of these actions require a set of tasks written in the project plan to execute.  I would like to offer just some hope that any of these steps is easier than the one before, but they each present challenges in their own way.  Testing is part of the build phase for most companies.  In some cases, there have been companies that decided not to test.  You will test, the question is if the testing will be in the pre-production environment or in production.  It's much cheaper to do it before it is rolled into production.

6)    Communication or the lack of is another area that can have a devastating affect on an ERP project.  In one case I was found a company that literally had no communication up the management chain on the project.  The issues that were found during testing or development were never shared with the team so the only way things were uncovered were when the proverbial stuff hit the fan. The bad news got trapped in the rank and file so risks continue to go unattended until it was too big to keep secret, and the cost to fix them were too high for the lower management to sign off.  The best practice here is to have an open and honest communication pathway all the way through the organization and project team.  From the very start, the executive team must insist on open and honest communication.  I have suggested to some of my clients that they should award those individuals who find the most bugs within the system. 

In the beginning of the project during the pre-launch phase, develop a communication plan that includes not only what you will communicate but how and how frequent.

7)    One of the parallel deliverables along with Communication is the development and distribution of project metrics. These too are perceived as difficult to extract from the project and hence, not very often included in the status reporting and communication model of ERP projects. Some companies support the PMP and PMI, PMBOK approach to project management, which can be effective, but besides the certifications, still requires a lot of attention to the project plan detail.  taking the project manager role for an ERP project has been equated like herding cats.  For a twelve billion dollar consumer products company, I suggested just five metrics at first to set the baseline to communicate with the executive team.  Once the metrics had been vetted and accepted by the team, another included 2 types of metrics were added for clarity.

First, always include operations metrics that will resinate with the executives as the metrics will be recognized as key business indicators.  Metrics such as Inventory Management, Procurement to Pay and other Key Performance Indicators or KPI are part of the daily operations of a business.  The final set of metrics introduced into the project are the financial metrics for the company, ROI on capital investments that are made, Cash flow and a budget to both forecast and apply the actuals similar to how most companies run a budget and P&L.  Having the financial metrics available to the team can change the payments and alter the cash-flow to the company.  At the end of a fiscal year, ask to hold payment until the first day of the next month which is the following fiscal year to save the cash flow.  If I didn't say it in the beginning, I should have: these projects are all about the money.  Be as sensitive to the spending and savings as you can be for the project.

8)    Risk Management will either help or cripple the project depending on what is being captured and how the team responds to the findings.  The failure numbers are tossed around in the software industry depending on the audience.  The high number is 80% failure and the low around 45%.  Neither number is good. The planning and allocation of funds and people is all about risk.  Without clear Risk Management, the ERP projects have the likelihood of going off the rails sometime during the project execution.  It is far easier to track the issues rather than attempt to rescue the project.

At a minimum, listing the risk on each track status report and highlighting the severe show stopper level on the main communication to the management team will help allocate and redistribute the necessary resources to mitigate the risk and make sure the project is on the right path.  JoMax Consulting LLC has developed a new metric that represents the Risk Tolerance in a new Risk Tolerance Model, Risk Mitigation Quotient™ or RMQ™ that can be used as an effective tool in describing risk in a quantifiable way.  This metric assigns a quantifiable value to the risk tolerance of a company or project.

9)    Governance is part of managing an ERP project and maintaining the controls similar to the defining the risk to the project.  The governance and oversight of the project should be considered well before a partner is selected or the project is put out for RFP.  Ms. Karen D Schwartz said in CIO online, “Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance.” I don’t think I could have come up with a better description for IT governance.  Governance is the set of processes that keeps the IT Projects aligned to the overall business direction and strategies.  Supporting the governance of the project would be the performance metrics and Risk model and administration.  There are volumes written on the IT Governance topic, this text is related to the broader delivery of a successful ERP project.

10) Most of the ERP projects I have been involved with include multiple phases and span multiple years.  One of the best practices I see is the use of documenting Lessons Learned and actually learning from the lessons as painful as they may be.  I have many clients who believe they are ERP experts because they have done 1 ERP project badly.  Sadly, it takes more than 1 project to learn what is needed, what patterns can be seen and how the plan maps out to the final cutover into production.  Learning is a continuous process, which hold true here as well.  Capturing the lessons at premeditated intervals during the project and summarizing them at the end of phases and actual projects is the only way to leverage the learning into the next project.  That is why hiring experts who have done the work previously is a benefit to the company.  So another best practice.  Talk to other companies and contacts that have gone through the deployment process of an ERP project and listen to their experiences, those count as lessons learned as well, they just didn’t hurt as badly as if they occurred to you. 

There are other best practices that should be included here, these seem to be the most obvious, and most neglected by companies I have seen struggle to deliver the ERP project.  I’m convinced, greater communication, a complete executable project plan that is managed with metrics and clear transparency is the key to reducing the risk of implementing an ERP project in any environment.  I am asking others that have other hints in managing the ERP project to offer them in the comments section, there are as many as there are projects.  

Testing - The 2 Universal Truths

I am writing today about one of the main reasons ERP projects fail! Failure is due to improper testing, or, the lack of testing at all. The current metric illustrates that less than 10% of projects deliver the results agreed upon. I am going to highlight testing and what can be done to ensure that the proper resources, including time, are allocated in the beginning of the project plan.

During my 30 year global career in I.T., I have found that there are two 2 fundamental truths about testing. The first truth is, you should always test! That's right, you should test. The focus should be about creating the proper testing environment. Optimal testing helps to identify problem areas early in this phase. Certainly, the sooner the errors are identified, the faster and more cost effectively they can be resolved. If the code is migrated to Production without review, any issue found then needs to be tested in Production. When Production becomes the testing environment it becomes very costly to fix due to outages and downtime necessary. The expense of addressing a problem in Production rather than in Stage or Test environments costs more significantly. The second truth about testing is that you want to find errors. During any testing, finding issues is a good thing! As long as there are errors, testing should continue. In a recent project, the SI had the company stop testing because they were finding too many bugs in the code... That doesn't make any sense and the SI continued to bill the company while the SI fixed the bugs it created.

Planning the testing process can be difficult and require a variety of resources that understand the business processes that have been identified. Each area is represented in the various sections of the project plan. In the testing section, there are added complexities in the timing and the iterative remediation of the issues. Each fix needs to be tested again to ensure the fix didn't break another section of code. One of the more interesting things about ERP systems and projects are the inherent connections and interfaces to the other modules across the enterprise. The testing effort ranges from simple unit tests through the end user testing and acceptance.

There once were two Oracle projects I was asked to review that had very similar issues. Both sets of   management teams lacked the visibility of the project and was moving into System Integration Testing or (SIT) because the SI said any issue found would be discovered and remediation would be completed well before User Acceptance testing, or (UAT).  They also indicated they would do the testing for the company, that never works because they don't know your business. Make sure Business Process owners are in charge of the testing and quality of the product.  In one case, the project went live and was a severe crash and burn, the other was saved by an independent review that set the project on another course.

There once were two Oracle projects I was asked to review that had very similar issues. Both sets of management teams lacked the visibility of the project and was moving into System Integration Testing or (SIT) because the SI said any issue found would be discovered and remediated prior to the next phase of the project. They also indicated they would do the testing for the company, which never works because they don't know your business. Make sure Business Process owners are in charge of the testing and accept the accountability of the system operations including testing. In one case, the project went live and was a severe crash and burn, the other was saved by an independent review that set the project on another course. 

In the first example, the project team/SI lied on the status reports to show all issues had been identified and fixed when in fact, the product was still in development and some of the key functionality had not been tested. That's right, an ERP system that goes live without testing the critical functionality and features, has little chance of success. There are further examples of the same behavior where one SI suggested, and convinced the company that no testing was necessary because they were implementing a Commercial Off The Shelf or (COTS) system, Oracle. After the independent intervention, testing was reinserted into the plan and to no ones' surprise, found thousands of errors and issues. This in turn added many thousands of hours of coding and re-solutioning back in the project plan. I will use better judgment here and not disclose either SI, or companies name, but the result of the first project was to stop the project for 18 months and finally reduce the scope of the Oracle footprint, while the second company ended the Oracle deployment and move to another solution...after 28 months of effort and cost.

Ok, so here is the part that many of you will like to see. How do you use the right amount of testing within the plan without going too deep or too wide?  I have identified sixteen testing events that could have a place in the project plan. There is also a very strong integration to the SDLC process that supports the control of code being promoted into Production, but that will be a topic for another time.

Here are the different types of testing that should be considered during an ERP project or any IT project that introduces added risk to the business: 

                   ─    Unit Testing

─    Standard Functional testing 

─    Data Testing – Master Data Management

─   Custom Functional Module Testing – P2P – OTC- Finance

─    Month End Close, Quarter End Close, Year End Close

─    SOA Testing – Integration / Interfaces

─    SIT or End - 2 - End

─    3^rd Party tools and Bolt-on Testing 

─    Regression Testing

─    Day in the Life – Load test

─    Destructive Testing

─    UAT  - User Acceptance Testing

─    Fail-over Testing

─    Back out and Recover Testing – Contingency Testing

─    Backup and Recovery Testing - Operations 

─    Production Cut-over validation - In Production

─    Operations and Monitoring / Alerts  

I don't have the room to expand on each testing cycle, but the names of the tests should be self-explanatory. OK, there are a number of variables and issues that are part of the testing process around who can test, what to test, how often and other tangents such as Automated Testing and the integration of the offshore model. I cannot possibly address each of these areas here in this format, but they are important to understand before the SI and project team launches into the deployment. The business is responsible to identify the critical areas to be tested and it is the Quality team who architect the tests to truly represent the business processes being evaluated. The team as a whole including the SI, project team and management needs to come together to deliver the code, test it, and remit the errors...oh, and re-test and re-test and re-test. Testing is a cyclical process, not a one-time event, so include the testing process throughout the duration of the plan.

The last piece of the testing puzzle is the tracking and monitoring of the testing and results. In most projects I have seen, the complexities and immense volume of data that is created doing the testing must have a method of both understanding the data and a better way to present it. Senior Management might have a clear view of the business issues, but depend on the testing experts to explain the details about the project, so the results and status must be very clear. I recommend a graphical representation of metrics and details whenever possible. You can always share more detail if there are further questions. I have included just one of the charts I use to present metrics and testing details I have developed over a number of years.

Let me know what you think, drop me a note at vince.benz@jomaxconsuting.com.  I am also available to discuss further issues around Testing and ERP.     

 

        

The Biggest problem with ERP implementations…Money

The Problem:

The ERP implementation field is covered with wrecked careers and businesses that did not survive.  In a recent Gartner report, 65% of all ERP projects fail and another 25% never meet the intended financial or functional goal of the company.  These failures are an accepted practice in the commercial software industry, keeping an arm’s length between the sale of the software and the numerous third parties that are available to implement the solution.  Not all System integrators are created equal.  I in no way include all System Integration Companies in painting the industry with one brush.   The project outcome is based on the quality of people and processes that are brought to the table,not the name of the SI. 

The cost to deploy this type of software is roughly 5-8 times the money spent to purchase it.  The SI creates the SOW that includes all the components to how the project will be run as well as details the cost of the project across such elements as milestones, resources, both on and off shore, hours, and expenses.  Many projects I have evaluated lack the clarity and visibility of the work product against payments to the SI.   More important is the payments are really structured as a payment schedule rather than payment for services.  If the money was distributed based on performance, many projects would be stopped midpoint for the code and configuration to catch up with the plan.  A stagegate process for checks and balances are an important process that includes code reviews and interum testing practices.   

It is the System Integrator who is responsible to bring the necessary subject matter experts or SME to the project in order to extract the value from the purchased software.  The tier 1 ERP vendors SAP and Oracle enjoy an estimated combined market share of 42% worldwide, there are over 350 other products that fill out the sector.  The major System Integrators have found a need and have developed “proprietary processes” that are sold to guarantee the success of the project.  These processes have been developed over a number of years, using collateral that seemed to be useful in prior projects. So, if the SI has so much experience, “WHY IS IT WE HAVE SO MANY ERP AND MEGA PROJECT FAILURES?” In 2 recent ERP projects I have been involved with, the SI systematically collected the monthly fee, and in the end, both companies lost multi-millions of dollars due to the poor performance and never completed a successful go lives. Remember, the System Integrator was hired because they knew how to execute this type of project and knew the issues that would be most significant to close.  What happened to the partnership and collaboration between the SI and the companies that are in need of help?    

When I say millions, I mean MILLIONS, like over nine digits.  In one case, over $100,000,000 was spent over 3 years on an ERP project that was driven over the cliff by the SI.  In the second case, the project was built completely in old technology and configured without the help or expertise of a solution architect.  The company never thought to bring in its own experts until it was too late and the money was spent.  This expertise is critical due to the level of integration within these types of systems; it is important to understand how the system integrates and impact other systems and uses the internal connection points. 

Neither project ever had a chance to make it to go-live.  The only saving point in the later project was the execution of the IV&V clause in the SOW and had an independent company review what was going on and was able to stop the project before it crippled their business.   Money aside, the only downside was the loss of money.  Not that money is ok to throw away, but we have read about other companies that have closed their doors after a catastrophic ERP or badly executed project event.   The cost of the project, remember millions, now must be written off because no value could ever be had from the project.

 

The Solution

Before I get into some of the corrective actions that I have used in putting these projects back on the rails, there are 4 things that happen during an ERP project that has gone badly.  Blame, Embarrassment, Accountability and Partnership / Teamwork breakdown.   Interestingly, blame is never a topic that companies or System Integrators what to talk about because it leads to litigation.  No one can admit fault because that will be used against them in a court of law.  The embarrassment is obvious in the company regardless of level of executive.  The senior executives and CEOs feel responsible for allowing this amount of money and time to be spent without clear accountability, and are very reluctant to share the failure with their board and shareholders. 

Most companies that jump into the ERP space usually are unskilled in the methods of what it takes for a successful implementation, but why should they?  Most have thriving businesses and are focused on their core competency and are looking for the next technology platform by which to grow.   Executives I have interviewed did as much research asthey could on the products and partners before engaging the ERP vendors.   Many hours of research are usually done to validate the capability of the product and the benefits are defined early in the process to balance the cost to the shareholders.  This is where it starts to breakdown.  Once the company selects the software, the System Integrators are asked to propose their solution.  Without having any knowledge of the business or what is necessary, each company that ventures into this space becomes dependent on the System Integrator for planning, resources, status, cost, and configuration of the system.   Remember, I put a disclaimer earlier in the article that not all System Integrators treat their customers badly. There are SIs that are very customer focused.  There are many components in putting together an effective team that includes both consultants as well as key business stakeholders that need to support the system after it is up and operational.    Select the partner carefully, interviewing all consultants on the project and getting each person to produce a resume to show they have the necessary experience and background to be as effective as possible.  Even get the resumes of offshore resources.  In most of the projects I was asked to evaluate, most lacked any visibility to who was actually on the project and even less of what each were doing to bring the project to fruition. 

If the customer company lacks the skills or understanding of the new product, it is important to hire resources to be the sounding board to the SI and is there to protect the interest of the company.  There will also be a point in the project that Knowledge Transfer will occur only if the people have been brought into the company as full time employees.  Without these people being available, the company will remain dependent on the SI for the foreseeable future.  Those are incremental costs that are seldom included in the original estimate.   The SI is a business the same as any other and can make decisions that are not in the best interest of the company.  Training here is the answer.  The more the company employees know about the new tool, the better result can be deployed.   

Finally, these projects can and occasionally do come out well.   The key is transparency and complete visibility of the status and risk of the project on a weekly basis.  That might seem like a tight schedule, but better to know everything is executing on schedule rather than find after a month or quarter, that issues or people or technology has caused a major challenge and cannot be recuperated.   Ensuring truthful communication up the chain of management as well as clear messaging across the organization will help alleviate rumors and keeping everyone on track.     Operation and Project metrics along with costs need to be highlighted on the status reporting to senior management.  References and checking on the resources within the industry can be a good way to show if the SI being considered is up to the work. 

The examples I have used here are true, the names have been changed to protect the ...well you get it, unfortunately, there are many other projects that are reminiscent of these examples.    I hope to give an update in a later blog.   Drop me a note on how you did executing an ERP project or mega project and the outcome, are you part of the top 10%? 

Running IT as a Business

JoMax Consulting Inc.

---

IT Relationships / Organizational Alignment

The disconnect between IT and the other functional business leaders in companies are widening every day due to the misalignment of strategies and lack of communication and business understanding within IT.

There are several layers of relationships that are critical in running an IT department as a business. The obvious one is the relationship internal to the IT staff and understanding the capabilities of the existing staff and the resources internally that can accomplish the projects on hand. The second relationship is the connection to the industry suppliers and vendors who offer added skills and talent that otherwise might be shallow and unable to deliver the specific set of business objectives. The third and most important relationship for IT is the relationship with the other Business leaders in the company. This relationship if successful will drive the strategy and direction of the company.

Application Portfolio / Strategic Alignment

Every company survives day to day by leveraging the information it collects on its Customers, Industry, Competitors, and Internal Processes and Data. The information that supports these activities collectively is referred to as the Application Portfolio. The mix of the different applications that make up the composition of the critical information generally are integrated to add more value in connective systems and maintaining the correct data relationships. Each executive team should understand the systems that are used in the functioning of the business and determine the critical nature of the system and set a risk tolerance to protect the company from a loss of data and valuable competitive information. The strength of the business application portfolio is imperative to executing and aligning the strategic planning processes.

Customer Centric IT

Without understanding the importance of delivering great service to customers and truly taking customer service as a strategy in IT, most business leaders will not have a great opinion of IT and, in the end, will foster an adversarial relationship. The constant struggle within IT is to demonstrate its value to the business leadership. Without focusing on the internal and external customers, IT remains a cost center that should be outsourced. Question: What do you call a company without any customers? An idea. No company can exist without customers, nothing happens. For when IT considers the company employees it supports as customers, the IT strategy can includes wording about IT as a service delivery engine, an enabler creating an expectation that IT understands the business. At a midsize defense company in St.Louis, I was able to eliminate the "helpdesk" and replace that function with Concierge Services. Each employee was considered our highest and most valued customer. Similarly to the company without customers, an IT department without customers is an IT department that does not have a place in the company.

Business Financials

Information Technology is one of the largest budgets in most businesses today. The lack of business acumen and understanding by IT is only offset by the arrogance of IT in the delivery of service. In order to run IT as a business IT must have a complete command of the operations and key business issues and strategies that are important to the company. I have seen some companies include a finance person reporting to the CIO, recommended by the VP of Finance or CFO. To have an organizational alignment between IT and finance is a good start.

There are several elements related to IT / Business Financials. Charge Backs have become an operational necessity to account for IT dollars spent in different departments. The cost to a department budget is directly related to the use of IT resources either by project or allocated cost. The management of operating expense or period cost and the capital budgets are now critical in running IT. The cost of people, training, hardware and software are among the high ticket items that add to the overall cost of IT.

Most IT budgets are being reduced over 5% year after year to allow the company to invest its financial resources in other areas of the business. The capital expenditures must have a realistic ROI to support the spend. The better IT executives can communicate the return on investment, the sooner the company leadership will include the IT input into the strategic planning process. The last element in IT finances is the use of contract resources and consultants. This approach to resource allocation can be beneficial to the company if done correctly, but can be very costly if not done in a way to recover the costs. The pay of consultants is somewhat higher than employees, but if the fringe benefit cost of roughly 40% is included in the rate, then the use of consultants for a project can be controlled based on the time the resource is on the project. When the project ends, the resource goes away, never increasing the SG&A of the company.

IT / Business Empowerment

There has been a real transfer of control in who is driving the technical solutions in companies. Historically, IT has suggested and implemented solutions to problems that may or may not have been on the business radar. According to Gartner, the IT worldwide spending will decline 6% over last year, putting a hold on a lot of technology projects. This reduction in spending changes the IT projects and Priorities. The list of IT projects that are approved are now being proposed by the company leadership with IT developing the service model and customer centric approach to projects and deliver of services. Solving true business challenges is now the mantra, putting IT infrastructure projects at a clear disadvantage due to the nature of the cost and lack of ROI.

More business centric projects will be addressed, whether it includes Payroll systems driven by HR, or Supply Chain systems encouraged by the other departments such as Operations, Manufacturing and Finance departments. IT must articulate the benefit of a solid infrastructure to mitigate company risk, and keep the company's systems up and running. This is the opportunity for senior management to think as a team and decide how best to use technology as a competitive advantage.

Conclusion

There is always good news; and that is IT can deliver value to the business even in the most difficult economy by being part of the business planning. Now is the time for IT leadership to engage in the business and to understand the strategies and direction. The projects should be aligned to what matters in the business such as eliminating cost in processing an order, or eliminating cost in delivering correct information which is accurate, timely and actionable.

By aligning the organization to the business and giving the IT leadership access to the planning and strategy of the company, IT can be better prepared to offer solutions that have a direct impact to the business. The application portfolio can be an important feed into the strategic planning processes. The IT management and staff now have the opportunity to change the model and be customer centric. By treating the company as the customer, service becomes the focus, not technology. The old adage "The customer is always right..." plays a big role here. By offering the highest Service Level Agreement or SLA to its customers, the business financials will also be a key focus in delivering value. The perception of some of the businesses today is that IT is disconnected and unaware what the business does to generate revenue. The overall effectiveness of IT is how it delivers value to the company. It is that value that can take different forms in tools, software, security and, most importantly, Customer Service.

Our Mission is to understand and deliver expertise at a reasonable price with exceptional results. JoMax Consulting has over 85 years experience in multiple industries such as Manufacturing, Aerospace and Defense, Pharmaceuticals, Chemicals and Services. vince.benz@jomaxconsulting.com

JoMax Consulting Copyright ©2009 All Rights Reserved.

Notify to Unsubscribe

Setting IT Priorities in a Difficult Economy

JoMax Consulting Inc.

Staying consistent with a theme, I wanted to continue to focus on setting priorities and identifying the right IT projects in an IT organization. Obviously, nothing is the same as it was 18 months ago. So, it remains a critical element in IT departments in every company to re-evaluate IT projects and more importantly, recognize the old methods and practices are no longer applicable to selecting and executing IT initiatives. In this article, I will describe the key components in their correct order, which metrics IT projects need to include and finally, why communication in this economy and tightening market is an all or nothing proposition.

Critical IT Priorities

Running an IT department is like reading the minds of all the stakeholders and understanding what are the hot buttons of the company strategy. There are several key items that require the attention of IT management that occurs on a regular basis. The top job of every manager, as well as IT, is to keep the company management free of legal problems. In keeping with that thought, there are several other areas that require attention specifically in HR and HR reporting, Subpoenas issued by law enforcement and other 3 letter acronyms, and Audit compliance whether it is SOX or financial reporting. Each of these legal issues carries a far bigger penalty to the senior management than a project not hitting a delivery date. These projects require resources and oversight to ensure the results support the overall health of the company.

The second sets of priorities are related to the security and availability of the computing environment. Without a reliable system, the company suffers. The entire technical stack of components including network, servers, middleware, apps and tools must be operational the majority of the time. System outages must be the exception and be managed such that it reduces the risk exposure to the internal customers. I will talk in more detail about the collection and use of metrics in another section, but the base IT operations need to have qualitative measures to demonstrate the effectiveness of the IT policies and processes that maintain an effective computing system. The protection of information within the applications along with the email and other data sets are the responsibility of IT. Recent news headlines have been filled with references of several companies being so lax in their protection of data, that hackers have stolen millions of customers’ credit and health information. Depending on your industry, some networks are more secure than others, but in the end, no one likes their data on the internet for all to see. HR and HR reporting also include legal reporting issues such as EEOC, AA, and others. The missed reporting has financial implications to the company in the form of fines and other penalties. The arrival of a state or federal subpoena at the IT department takes stress to a new level. Communication here is your best approach. Besides satisfying all requirements, it is vital that the right executives are included in the discussion. The attorneys on staff are also very helpful in these situations and should be consulted before anything is processed. The final legal situation in setting priorities is the audits. Depending on the company status as a public or private enterprise that have outstanding debt that is publicly traded, Sarbanes – Oxley or SOX audits are required. There are more legal requirements that come up during the course of a career, but be forewarned the first priority of any manager in IT is to keep the company and its leadership protected.

System availability and the reliability of the systems, network and applications is second on the top list of IT priorities. If the systems are not online, then the business can not perform the necessary actions to sell product and invoice to generate revenue. One place never to be caught in is between the VP of finance and the month end, quarter end or worse, yearly end close! By setting clear expectations around availability, operational metrics become tools to establish a good reputation and the reputation of the IT team as a whole. So legal first, protection of information assets next, then the overall availability of the system, network and servers comes in a close 3rd.

Customer facing applications either web based or client server is next on the list. This seems to be self evident, but it is not always obvious. As web applications become the standard in customer interfaces to the company, the system connection becomes a mission critical application. If the customer has difficulty finding, ordering, or purchasing the company products, frustrated customers will find another source and stop being a customer. Going back to the protection of the company, losing customers is not protecting the company.

The true IT projects that make the list are directly related to the payback and alignment to the overall company strategy and direction. The heavy capital projects that require many years of work and a boatload of money will run into trouble justifying the project unless it has a clear reduction of people, or replaces a system that reduces the dependency of a legacy application, or most likely, eliminates cost of other systems or maintenance. Return On Investment, ROI, becomes a key measure of the likelihood of putting a project on the list. The higher the ROI, the more likely it is to satisfy the financial approvers. A 15% ROI is a good start to consider the project, the higher the better.

Red Flags

The red flags go up when a project has little business sponsorship and is in direct conflict with the company direction. Pet projects, unapproved projects, and projects that require a higher upfront investment are the projects that draw much more attention from those that might be more critical to IT projects. Consider the effect of cash flow and the timing of payments to consultants and other vendors and suppliers that might have a negative impact on financial reporting. Most companies that I have dealt with have agreed to delay the payment until after the month end close or financial event.

Metrics and Measures

When systems go down, the impact to the user community can be devastating. The loss of work or the impending deadline to get something to a boss is always looming over an outage that seems very short, but none the less, has made a customer dissatisfied. The creation and review of metrics offers several benefits to a company and IT department. First, it broadcasts to the company that IT is aligned with the business and has a good appreciation of the impact an outage to the deliverables, efficiency and productivity of the company. Below are some metrics that were collected and presented every day at 8:30 am for management review and comment.

By establishing daily metrics that accurately describe the computing environment, the user community can build realistic expectations as to how often the system is up and available. In the case of the metrics above, every minute was counted and applied to the measures for reporting purposes. This level of detail is generally not expected from the senior management team, but was important to show IT understood the systems and networks that were important in running the company.

Project Planning in Difficult Times

This could be a topic all by itself, but I wanted to share just a few ideas as to what types of project issues take a bigger role in this type of economy. For projects that are approved, there will be a bigger demand on the IT team and project team to show why the project was selected in the first place, so metrics similar to what I showed previously need to be incorporated into the communication plan. The milestones and project gateways must be managed to determine any risk to the business or project as early as possible. Most project plans include many tasks that are dependant on other tasks and resources. One area that is often overlooked is the unplanned events such as software bugs, and difficulty in converting data. I have been involved with over 85 ERP implementations and the data shows each issue with the software can add up to 14 days to the project plan. If the System Integration testing is scheduled for 2 weeks, then finding a problem during that stage creates a critical path issue that will delay the project. Even with identifying a reserve, most software / application projects have more than one issue.

The status report and weekly meetings help shed light on problems, but a clear and broad communication plan is most effective in dealing with problems and risk.

Conclusion

The good news, IT can deliver value to the business even in the most difficult economy. There are two main areas that companies can cut cost to save enough money to have an impact on the financials of the company. First is capital and the second is people. The reduction of headcount obviously makes the project resources less and the need to communicate even more important. Once the metrics are established and are being collected, it is critical to document the results on an ongoing basis. By documenting the priorities within IT, other departments have an opportunity to offer insight into their needs and have a discussion about changing what is considered a good project. IT does not set the priorities of a company, each of the departments such as Finance, HR, Engineering, and Business Development are responsible for deciding what is to be addressed to make the company more effective and competitive. In order to have an IT department that adds competitive advantage, there must be a partnership with the other departments to set the priorities.

Protecting your IT Assets in a Down Market

JoMax Consulting May 5, 2009 http://www.jomaxconsulting.com/ In these difficult times every company, especially small and medium size companies need to optimize their IT investments. The JoMax Consulting company provides critical technical resources that compliment your in house Information Technology team. We specialize in Small to Midsize companies that do not have the talent to drive the Strategic Planning, CIO Services, and Project Management required in these difficult economic times. JoMax Consulting has experience in transforming business through successful execution of ERP implementations, development of successful Business Intelligence solutions and Data Integration and Mining. JoMax Consulting company will assist you by providing seasoned expertise in assessments, process analysis in Software Development Life Cycle (SDLC), Change Management, Project Management and improvement services, while offering unique requirements for your company. Our services deliver maximum return on investment. Protecting Your IT Investment in a Down Market Jim Crammer said it best, "cash is king" referring to companies and individuals that have cash on hand to spend in this weakened economy. There are several key considerations in protecting your IT investment in a down market. The business planning process takes on new meaning when the spending of IT, which is usually higher than most other departments, is reduced and the headcount is cut or the payroll expenses are eliminated. As much as people are the most valuable asset, they are also the most expensive. Business IT Planning Now is the time to rethink the IT plan and highlight the key priorities that will facilitate the growth of the company as the economy recovers. There is a related process chain of issues that left unattended causes disruption and a gap in the company's operational processes. The planning phase is connected to visibility into the company key suppliers, inventories, cost and most importantly, your customers and the effect of the down turn on their needs and constraints. Timing Once the planning is revisited, the visibility into the top priorities assists in determining the best places for reductions or further investment without killing the key projects or people that would have had a great result. Timing of the investment is critical as well. To spend or not to spend; it isn't mutually exclusive. The timing of any purchase must be weighed against cash flow. There are good times to buy and to not buy and delaying spending money. At the end of a month, quarter or year, all payments should be held to reserve the cash to close the books. Most suppliers will work with you to delay payment until the first of the next month so not to have a negative impact on the close. Also, the purchase should be timed to align with the month end, quarter or year end of the vendors so to gain the best discount the vendor can offer. The Best Way to Protect Yourself The best protection of your IT investment is to make sure the systems are well maintained and secure. As the IT staff is reduced, the activities that were completed regularly become more sporadic, and in fact, some cease to be done simply because the task was never documented and no one else knows how to do it. Make sure all processes and procedures are well documented so even if an outside consultant is brought in on a short term assignment, the overall operational effectiveness of the IT assets will not be diminished. Conclusion These are uncertain times! The propensity to sit and wait for the economy to improve is outweighed by the risk of your critical systems and life lines to your business cut off or your customers swept away by competitors who have used technology to their advantage. Planning, understanding and evaluating the ROI and impact of IT projects shines a bright light on what is important to your business growth and in some cases the survival of the company. The upside to the current economic situation is the abundance of IT talent available at a reasonable rate combined with vendors and suppliers willing to offer deep discounts for companies with cash to spend. By smartly investing in IT today, your company will be poised to ride the wave of recovery and will be better prepared to compete in a new more competitive market. Our Mission is to understand and deliver expertise at a reasonable price with exceptional results. JoMax Consulting has over 25 years experience in multiple industries such as Manufacturing, Aerospace and Defense, Pharmaceuticals, Chemicals, and Services. vince.benz@jomaxconsulting.com http://www.jomaxconsulting.com/ JoMax Consulting Copyright ©2009 All Rights Reserved.