Some of our clients have sales teams and project teams that are located in different cities and towns acrosss the country. We have observed their process for routing expense claims to be slow, resource-intensive and cumbersome. The employees are typically expected to fill in vouchers and attach supporting documentation such as bills and submit them for approval. These claims are then approved by a local authority and then passed on to the central accounts department.

From our observations, having supporting documentation is a necessary evil. However, most of the paperwork is required primarily during initial approval by the local authority, and subsequent consolidation by centralized accounts can be much simpler if all the expense claims are digitally recorded in a central repository that is accessible to all locations.

The Expense Claims Workflow that we built provides the following procedure for expense claims:

The workflow proceeds as follows:

1. The employee situated at any location logs in to the application, enters expense claims using a simple form, that could be integrated with any other workflow such as the Sales Activity Management workflow, or Order Processing workflow.
2. At the end of the week, the employee takes a print-out of the report showing the expenses incurred during the week. He hands over this report, along with supporting documents such as bills cash memos, etc. to the local area manager. The area manager logs into the same application and views the claims and verifies them against the supporting documents, where relevant. The area manager may mark expenses as:

   Approved: The area manager may approve all or part of the amounts claimed. Those expenses approved by the area manager are forwarded to Accounts on a weekly basis. (The collective printouts of the expense reports along with the documents are forwarded by courier each week).

   Clarification: Expenses marked for clarification are sent back to the employee for clarifications. The employee gets an email alert with a link to the expense in question.

   Denied: Expenses marked as ‘Denied’ by the area manager may be reviewed later with the employee as required and can then be re-submitted subsequently.

3. The Accounts department at the head office receives all claims approved and forwarded by area managers from all locations. Accounts then looks up these claims in the same application. Accounts can then mark each claim as:
   Approved and Locked: Expenses approved by accounts are considered Passed and Locked. Approval may be granted for the entire amount or part of the amount only. The area manager then cannot modify the approval status.

   Clarification: Some expense claims may be returned to the concerned area manager or employee for additional clarification.

   Denied and Locked: Expenses denied by Accounts are considered final and locked. The area manager then cannot modify the approval status.

In the above workflow, all concerned persons, such as the employee who entered the claim, the area manager, or other persons with supervisory roles and permissions, may track the progress of each claim through the entire workflow. A stipulated time frame can be set within which claims are to be processed through the system, failing which alerts are generated and the defaulting claims are escalated to top management.

Finally, the expense information is tagged against other information in the workflow system, such as:

• Employee who incurred the expense
• Location / Division where the employee was located when the expense was incurred
• Expense Account Head
• Customer or prospect that was served
• Sales opportunity, project, or order against which the expense was incurred
• Travel, customer visit or other event that resulted in the expense claim

Due to the fact that each claim has all this information tagged to it, a detailed analysis can be provided that tracks the levels of expenditure by various above fields.

We shall soon post sample screen shots, analytical reports and graphs that the system generates.

We would like feedback and suggestions regarding any additional features that we could incorporate that may make the system more useful in different usage scenarios.

Related posts:

1. Communication Problems are actually Process Design Problems When working in teams, small slip-ups and sometimes big goof-ups...
2. Software for Everyone How hardware vendors are bringing down costs of hardware, and...
3. Performance Incentives – Risks of being counter productive Daniel Pink gave a brilliant talk on TED about the...

Everyone believes that Information Technology can do wonders to the productivity of an enterprise. Yet, as a business owner, it is far from easy to put your finger on exactly what IT can do for a small/medium sized enterprise. A previous article attempted to answer this question – What can Information Technology do for a Small/Medium Sized Business Enterprise?. It discussed how an enterprise can create a Business System, consisting of processes and policies that are used by people and resources, aided by information technology, to generate enhanced performance.

Once a business owner is convinced that IT can enable higher performance, and is prepared to upgrade processes and policies to make them techno-savvy, the next important questions are:

• Which technology solution to choose?
• What are the risks involved?
• What are the costs involved?

We shall attempt to answer these questions here.

Which technology solution to choose?

Technology is undoubtedly one of the fastest growing industry sectors. And this growth is accompanied by innumerable options provided by IT service providers ranging from hardware manufacturers, operating systems, database systems, application software, connectivity, etc. that all form part of the solution. To complicate matters, each service provider introduces new jargon that purportedly differentiates their product or solution from the rest and rises above the noise. But as a business owner, all this makes the decision of choosing the right combination of technologies and providers extremely difficult.

In an attempt to reduce the noise and get some clear picture about what technological options one needs to consider, we have taken the metaphor of constructing a building. We have identified three basic areas in which one needs to make a choice, while selecting a technology solution:

1. Architecture
2. Construction
3. Ownership

The diagram below lists out the choices in each of the above three areas:

1. Architecture

The three types of architectures available for implementing an IT solution are:

1. Stand-alone – where a single computer contains the entire solution – stand-alone solutions are useful for personal productivity applications like word processing, spreadsheets, email, etc. where a single individual creates information and accesses it from a single computer, with little or no requirement to access the information from anywhere else.
2. Client-server – where the solution involves a server on which the main application and data is stored, and client computers where special client application software is installed for accessing and processing information from the server. This model is used extensively for conventional enterprise applications that require information to be captured and accessed by multiple people connected to each other by a network.
3. Web-based – where the solution is primarily installed on a server, and is usable from any client computer with only a web browser – no special client application software is required to be installed. This model is suitable for applications where information is to be captured and accessed at multiple locations that can connect to the server via a network- including via the Internet. Web based solutions are gradually becoming widely available for all types of requirements.

2. Construction

The four construction options are:

1. Standard Product – This option represents solutions that are available as standard products. The product encapsulates a set of built-in features, much like a pre-fabricated building. If the features available in the product are a good fit for the requirements of the business processes and policies, a standard product may be a good choice.
2. Customized – Several standard products have facilities to configure and customize features, requiring varying amount of expertise. The amount of customization required to achieve the required facilities is the prime consideration to choose this option.
3. Custom-built – Custom-built solutions have a high degree of flexibility and can be built to suit the exact requirements of the business. However, the costs and risks can be higher. New development methodologies like Agile Development, can minimize these costs and risks.
4. Open Source – Open Source applications have emerged as a new option for constructing IT solutions. Built by teams of programmers who collaborate by volunteering their efforts without compensation and for mutual benefit, several open source applications have grown to become feature-rich products with complete source code available to any user. Enterprises can use open source applications with low upfront investments, and with relevant technical skills, can customize the code to match their requirements. Open source alternatives for basic requirements like email access, web site management, basic collaboration, etc. are now easily found, but applications for business process management are few and not yet mature enough. However, this is a space to watch.

3. Ownership

1. Purchase (License) – Conventionally, most software products are available in this model. Payment is made once, and the purchaser is given a license to use the software with certain restrictions based on number of users, computers, servers etc. as per the license purchased. This model does not take into consideration, the frequency of use of the solution, or the features used. The purchaser usually pays for all the features in the product, irrespective of which ones actually serve the requirements. This model usually involves products that are physically installed on the purchaser’s own computers.
2. Rental (ASP) – A new ownership model is emerging as an alternative for some IT solutions. Enterprises can rent an application that is physically installed on the service provider’s computers and accessed by the purchaser via the Internet. The service provider is called an Application Service Provider. This is still an emerging model and not many applications are available.
3. Per-per-use – This model of ownership is an extension of the Rental model, but instead of paying a fixed recurring fee per user or per period (month or year), the pay-per-use model allows the user to pay for every usage. For example, online payment services usually allow a model where customers with a small number of transactions can use the service free with charge deducted for every transaction. Similarly, software solutions that are not used often – for example, online surveys, marketing campaigns etc. can follow a similar model of payment.

Choosing the right combination

We have seen above, that the permutations and combinations of options for choosing a technology solution are several. To choose the right mix of architecture, construction and ownership, a cost-benefit analysis needs to be made. The benefits one needs to consider are in terms of :

1. Suitability to current requirements:
   1. Is the solution suitable to be used by the number and nature of people and resources in the business system?
   2. Is the solution suitable for handling the processes and policies of the business system?
2. Flexibility to handle future requirements – For how long can the solution serve the business system? Can it handle the changes in the business system that are inevitable during the time frame planned? Will the solution handle the growth expected?

What are the risks involved?

The next important issue to be considered while choosing a solution are the risks involved. Statistically, the failure rates of software projects is extremely high – over 90%! The factors attributed to failure of software projects are :

Project Challenged Factors	% of Responses
1. Lack of User Input	12.8%
2. Incomplete Requirements & Specifications	12.3%
3. Changing Requirements & Specifications	11.8%
4. Lack of Executive Support	7.5%
5. Technology Incompetence	7.0%
6. Lack of Resources	6.4%
7. Unrealistic Expectations	5.9%
8. Unclear Objectives	5.3%
9. Unrealistic Time Frames	4.3%
10. New Technology	3.7%
Other	23.0%

(from the CHAOS Report by the Standish Group. See Why software projects fail – and how we make them work for more details)

As seen from the above list, some of the major causes of failure of software projects is related to user inputs, and requirements. In conventional software development methodologies, requirements were expected to be completely defined, and unchanging atleast through the lifetime of the project. However, if we look at how IT helps a business system, software is merely an enabler for a business system to deliver enhanced performance. It cannot be successful unless the processes and policies are re-designed to take advantage of the technology. In such a scenario, working out requirements needs an assumption about how the upgraded processes and policies will work. Such assumptions can easily be found lacking, and when actually implemented, may require changes and re-tuning – which in turn may require the software to be changed too! This is what causes the most failures in software projects.

These risks are minimized in the emerging technological options – such as web based architecture, agile development and rental applications.

What are the costs involved?

When choosing a technology solution, one needs to consider the total cost of ownership of the solution. An IT project typically involves the following costs:

1. Hardware – servers, client computers, peripherals
2. Platform – operating systems, basic server software applications like database servers, web servers etc.
3. Application Software – License, Customization, Development, Hosting
4. Connectivity – Network, Internet
5. Training – upgrading manpower skills to utilize the new processes and policies in the context of the new technology
6. Administration – Every solution needs to be administered. Administration requires expensive skills that an SME may not be able to completely justify
7. Support & Maintenance

Costs are easier to manage with the emerging technology models – such as web based solutions, agile development and rented solutions.

Conclusion – go for IT as a service

If we look at the general trend in new technological developments in architecture, construction and ownership, the trend is to convert Information Technology Solutions into a full-service.

The above diagrams shows a comparison between implementing IT solutions as a product v/s IT solutions as a service. The diagram on the left shows the conventional options of IT solutions – stand-alone or client-server architecture with standard or customized products, owned by purchasing licenses. While the diagram on the right shows emerging IT as a service options – web based architecture, with custom-built agile applications or open source applications, owned as rental or pay-per-use solutions.

Bottom-line: Choose IT as a service
But where are these options available?
Contact Us to find out.

Related posts:

1. What can Information Technology do for a Small/Medium Sized Business Enterprise? Small businesses owners are hard-pressed for managing with scarce resources....
2. Why Open Source? What role does open source play in bringing affordable technology...
3. Software for Everyone How hardware vendors are bringing down costs of hardware, and...

Software projects are known to have a high level of failure. How high? The often referred study on software project failures, published by the Standish Group is called the CHAOS Report. It is a result of analyzing software projects in the US.

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

This quote from the report draws a dismal picture for software projects. Another interesting finding of the report are the factors and their relative importance in contributing to the success or failure of projects.

Project Challenged Factors	% of Responses
1. Lack of User Input	12.8%
2. Incomplete Requirements & Specifications	12.3%
3. Changing Requirements & Specifications	11.8%
4. Lack of Executive Support	7.5%
5. Technology Incompetence	7.0%
6. Lack of Resources	6.4%
7. Unrealistic Expectations	5.9%
8. Unclear Objectives	5.3%
9. Unrealistic Time Frames	4.3%
10. New Technology	3.7%
Other	23.0%

Software developers are aware of these factors. And the fact that the first three factors being beyond the direct control of the development team only proves that the often used – ‘not my fault’ excuse by developers for failed projects is not totally unfounded.

Development Methodology

The main factors for software development failure are lack of user involvement and incomplete or changing specifications. The reason these factors are so commonly attributed to failure of development projects is largely the development methodology used for most software projects. Conventional development methodology involves creating up-front systems analysis and specifications design of a project spanning a large number of features that require several man-months or man-years of development. Development is then carried out in an extended development cycle assuming that:

• the specifications are clearly written
• the interpretation of the specifications by the developers matches the user’s expectations
• the expectations of users do not change during the development cycle

All these assumptions are highly unreliable. User involvement in such a project begins only after the development cycle is almost or entirely completed. This results in the inevitable ‘this is not what I meant/want’ response.

Agile / Adaptive Software Development Methodology

Software development methodologies have evolved in the last decade that incorporate:

• close collaboration between the programmer team and business experts
• face-to-face communication (as more efficient than written documentation)
• frequent delivery of new deployable business value
• tight, self-organizing teams and
• design of code and development teams in a way that minimizes the risks of inevitable change in requirements.
  These Agile or Adaptive Software Development are now following in various forms such as Scrum, Crystal, XP (Extreme Programming), etc. and are based on the realization that building software is not like building an immovable asset such as a house or a bridge. Software is a movable asset in the sense that it needs to change over time and space. Software is a tool for humans. Humans change, requirements change and hence software needs to change not just a few times in the form of project or product upgrades, but continuously, as a process of evolution.

  The Agile Manifesto is a statement of shared development values crafted by various originators and practitioners of these agile methodologies:

  We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

  That is, while there is value in the items on the right, we value the items on the left more.

  Reach1to1 Methodology

  At Reach1to1, we have adopted a methodology that is based on the agile manifesto.

  1. Development of Process Scenarios (User Stories)
     A Process Scenario or User Story is a description of tasks that are performed by users in typical scenarios while interacting with customers. The stories will also describe how the processes will be facilitated by the software. The stories will not describe the software in technical terms, database layouts or algorithms. They will use the language and terminologies normally used by users.

  2. Release Plan for entire project
     The release plan specifies which user stories are going to be implemented in which development cycle, and dates for those releases. The release plan is finalized together by the entire team.
     Also during the release plan, the infrastructure requirements are laid out in terms of the hardware, operating systems, other supporting software platforms etc.

  3. Small Release Cycles (as planned in the release plan)
     Development is carried out in several small cycles lasting not more than 4 to 6 weeks each. Each development cycle will involve:
     1. Scope Planning
     2. User Interface Prototype
     3. Software Development
     4. Unit and Functional Testing
     5. Installation on site
     6. User Feedback
     7. Fine Tuning as required

     The scope for each cycle will be planned in a way that it can be completed in not more than 4-6 weeks from the start, and the results are usable and testable by the users. Each week there shall be a review meeting of the entire team for assessing the progress of the cycle, and modifying the scope if necessary so as to ensure its completion on time, and with acceptable results.

     Scope plans for a new cycle are started only after the previous cycle is completed. This ensures that the clarity achieved by the users and developers are incorporated into the plan for the next cycle.

  Other principles that maximize project success

  In addition ot using an agile development methodology, Reach1to1 also uses the following principles:

  • Affordable Technology
  • Component Based Architecture
  • Object Databases

  to build and deliver custom-built solutions that automate business processes in a way that maintains the high levels of flexibility, scalability and efficiency that is required especially by evolving enterprises.

Related posts:

1. Software for Everyone How hardware vendors are bringing down costs of hardware, and...
2. How to choose technology solutions Information Technology is rife with jargon. Every IT enterprise creates...
3. Making LIMS Work LIMS - Laboratory Information Management Systems - specialized applications for...