Information

Cash-flow Models:

There is a secret in the design of cash-flow models that's commonly over-looked, yet implementing it can improve the quality of cash management and cut down on the amount of management time spent on it. It can do this more effectively than planning tools like Cognos and without the big capital investment.



Would you like your cash-flow model to

  • quickly identify the high and low points in the cash-flow
  • see what's changed between forecasts
  • show the likely effect on future cash-flows of commercial decisions before they're negotiated
  • measure behaviour of key assumptions
  • learn from past behaviour, i.e. have the model become more intelligent
  • better predict cashflow so you can stay within headroom, earn more interest in the money markets or obtain greater levels of discount
  • present information in an easily understandable format to the wider management team
  • naturally roll forward, i.e. the model doesn't need to be re-invented each year or each quarter, it can calculate the per day cash-flows for more years than you'll ever need.

By applying the proper design rules you can actually accomplish all this with a simple spreadsheet, and it will give you the ultimate business tool in flexibility, but at a fraction of the cost of Cognos.

But of course, you must apply the right design method, and the majority of spreadsheets don't. A very common flaw is to design the model in report layout format rather than separating data from the report.

This is the key secret. Don't design in report layout format, separate the data and the function values from the reporting aspect.

You also need to add in some phasing algorithms, some VBA and you need to switch on the Analysis ToolPak in Excel to get a model that perpetually rolls forward and will vastly improve your cash-flow planning. This is as important when you're growing as it is in difficult trading conditions when you don't seem to have the support of your bank, you're being downgraded by the Credit Insurers and your Suppliers are reducing their credit terms with you.

Would you like to know more? Contact now





Information



Planning

Don't Plan to Fail

If it hadn't already been attributed to an anonymous source, the oft quoted truism "If you fail to plan, you plan to fail" might have been the concluding words of a KPMG study into failed IT projects. The 2002 research paper found that, in the preceding twelve months, 56% of the 134 listed companies surveyed had to write off one failed project at an average cost of £8m. The key reasons cited for failure were poor scope management, poor planning and poor communication.

Lets look at some of the things you can do to ensure your project is successfully implemented rather than becoming another systems casualty strewn across the metaphorical train tracks.

Listed below are twenty of the key things you should plan to do if you don't plan to fail

Top 20 Project Plan Considerations


  1. Nominate a Project Sponsor
    • From the outset the project has to have and be seen to have the right level of gravitas in the organisation. Nominating a project sponsor from the Board is an ideal way to accomplish this.
    • The Project Sponsor is not a hands on role but will have overall responsibility for the project. If it needs a course correction or a final decision the sponsor has the influence and credibility to get it done.
  2. Know why you want a new system
    • There should be clear, not vague reasons why you want a new system. There are likely to be both push and pull factors contributing to your decision. Write them down.
    • If people understand why the system is being changed then you're part of the way to obtaining their buy in, essential if a new system is to work.
  3. Define your project goals
    • What do you want to deliver and achieve with the project. Are there tangible financial benefits to be realised? Are there efficiencies in processes, clear improvements in stock control? Are you looking to enable electronic invoicing or eprocurement?
  4. Identify your resources
    • Identify both your financial and staff resources. How much is the overall budget? How long is the payback period? Do you have the staff resources and skills to deliver the project successfully?
  5. Define the scope of the project
    • You need to know what the project is going to include and exclude. If you don't define this clearly you can easily overspend and over complicate the project.
    • Remember people are trying to sell you consultancy, development hours, software and related add-ons. If you don't therefore define the scope you're putting unnecessary risk into the project and in delegated responsibilities.
  6. Keep it simple
    • There is always a risk of the project becoming too complex. This can arise from the project scope going out of focus, consultants trying to sell you more consultancy, change requests being agreed at too low a level, too many technical people making a decision and so on.
    • The overriding rule should always be "Keep it simple"
  7. Identify dependencies
    • Departments and people don't work in isolation. Decisions, unless informed with expert knowledge, should be made in consultation, not in isolation.
    • However, too much consultation can delay projects. It can lead to too much talking and not enough doing, so there are times when you have to make a decision as you'll never get consensus.
  8. Redeploy or recruit a project manager
    • It's not uncommon, in fact it is quite usual, for the vendor to supply and charge you for project management, but this is not necessarily the best solution.
    • Firstly they're employed by the vendor, secondly they don't understand your business, and thirdly they're very rarely on site. As a result they can lack the independence to effectively mediate or bat for your business. In addition, as they're likely to be running multiple projects you're unlikely to have their full attention.
    • If you appoint someone internally you may need to consider back filling their position. At various stages they will need to devote their entire time to the project. Be realistic and don't overestimate their abilities or credibility and profile in your organisation.
    • Independent, specialist project managers or pmo teams are also worth evaluating. Firstly, they're independent, secondly they're experienced, and thirdly they're likely to have the breath of business, process and systems knowledge needed for successful implementation.
  9. Establish the steering group
    • The project steering group should be an inclusive team, i.e. interested parties are represented. Again this is going to help the overall buy-in and acceptance of the system. It should also insure dependencies are understood and agreed between teams.
  10. Identify the risks in the project
    • What are the key risks in the project and how could they impact the business. If you know what the risks are then you are able to manage them.
    • For example, there is a risk that users will not buy into or accept the new system; the impact of which could result in staff turnover through job dissatisfaction, poor service, loss of customers etc. Things we might be able to do to mitigate against this risk could include.
      1. Steering group includes representation from all interested parties
      2. Information is deployed within the organisation via the intranet and "department huddles" so everyone can understand why a new system is needed, why this one was chosen, what is included in the project etc.
      3. "Ground crew" are included in testing
      4. There is an open forum on the intranet where people can have their say and feel included.
      5. Customers know in advance that we're putting in a new system to further improve and build on customer service.
    • Not all senior executives may agree with the implementation. Without support from the top a poison can trickle through the project unless you identify where the loyalties lie and are able to resolve them or work around them.
  11. Be Flexible
    • There will be ups and downs in the project so you need to retain a flexible attitude and be able to adapt to change. Although you need a timetable you should use it for guidance rather than rigidly adhering to dates at the expense of the project. A difference of a few days isn't likely to be a disaster if it means you don't have to wing it.
  12. Manage expectations
    • Don't allow the illusion to develop that the new system will solve everything because it won't. It will not catapult us into the space age. Responsibility for internal controls will always remain with staff and not with the computer.
    • Communicating the goals and scope of the project are essential to keep it grounded and to keep the expectations of users balanced in reality.
  13. Define the project timetable
    • There has to be a timetable and usually events need to occur in a certain order. Progress against the timetable needs to be measured or there is a danger of it never ending or of consulting days pushing the project over budget.
    • The timetable needs detailed tasks in addition to key milestones. Use a time based spider or radar graph to monitor actual performance against plan. Every project needs an early warning system pegged at the right level to ensure the project doesn't go off the rails.
    • But don't let the timetable become an end in itself. The main objective is to successfully conclude the project. Be cautious of linking bonus payments to rigid milestones. If something is three days late it's not the end of the world.
  14. Create the plan
    • There must be a documented written plan that people sign up to. The plan should include a timetable with detailed actions, key milestones, responsibilities, budgets and performance measures. This can be easily written up in a spreadsheet. If you write it up in anything else you might limit access.
    • The plan should be transparent and if not widely distributed certainly be available in some form so users are unable to opt out and say they're not informed.
  15. Create user buy in
    • Nothing can create more buy out among users than the feeling that their opinions have no value, they've not been listened to, or worse they've been ignored. There almost becomes a psychological willingness for the project to fail as it provides proof and a validation of the value of their input. If their input was taken onboard things would have occurred differently. The project failed because it didn't include them.
    • If your users feel they have contributed to the selection, design and implementation of a new system then the same psychology will apply but directed at success rather than failure, there will be a willingness for the project to succeed, people will go the extra distance to make it happen.
  16. Define an authorisation matrix and escalation process
    • The sign off of any items outside of the project scope need to be made at an informed level. There needs to be a clear authorisation matrix for approving any change requests or spend outside of scope so that both vendor and your organisation understand the financial policies which will be used during the project lifecycle.
    • The escalation process needs to also be understood from both the perspective of the vendor and your organisation. Don't wait for a crisis to determine what it is.
  17. Regular review of budget and progress against milestones
    • A properly devised plan will include measurements. These will be a combination of financial and time based milestones. The review of financial information needs to be in sufficient depth to understand the effect of any timing delays, i.e. does a seemingly on target result net out an overspend on one part of the project with an under spend on another part. As the under spend may only be a timing delay project costs reviewed need to be forecasted to the end of the project.
    • Use a spider or radar graph to provide an "at a glance" status report of performance against milestones.
  18. Understand your data
    • Your old data is unlikely to map without effort into your new system. The time it takes to clean and map data is not to be underestimated.
    • Decisions need to be made about what data you want, what data you have, what data you're able to have. In addition, the structure of your data may change, such as product codes, product trees, business partner codes, chart of accounts etc. You may have data in multiple sources which you now want to consolidate in a new system.
    • Your data includes standing data and transaction data. Your standing data such as customer and product records may be key for the project but migrating the history may not be. Mapping transactional records into a new structure might not have any value at all if you can still access the old system. If you're taking this decision it should be understood by the company to keep expectations managed.
    • The earlier you can understand what the mappings are going to be, i.e. what your new data will look like, the earlier you can start building familiarity with users. During implementation it can also be beneficial to provide lookup functions from old code to new code and vice versa. This can be easily written and deployed via your intranet.
  19. Due Diligence
    • Your due diligence needs to cover
      1. the software
      2. the company delivering it
      3. it's fit to your business, and
      4. the consultants implementing it.
    • Ensure your RFI or ITT asks the right questions. Take telephone references as well as going on site visits. Obtain copies of insurance certificates, financial statements and consultants CV's, understand the database and programming languages used, version numbers, frequency of major releases, problems in upgrading etc.
  20. Read the contracts
    • You are unlikely to get the software before you agree contracts. This is one of the easiest ways for a timetable to slip.
    • The earlier you get a hold of a standard contract and read through it the better. You need to be very wary with control over contract versions and changes. Every time you get a contract back you need to read it in its entirety. Versions can be accidentally mixed up or new clauses included which mitigate your changes.

Inspired Notes

SAP Oracle Sage Coda Microsoft Dynamics

Resources

©newITsystem.com 2010, all rights reserved ::

Design: Eriginal