Maximizing ROI
In addition to what has been mentioned, you’ve probably already done your own research into the capabilities of MOSS. The information about the product describes it as a powerful and simple product that companies can use to quickly change the way they do business. This is all great news, but understanding the best way to realize value from your investment in MOSS is something that many companies find challenging.
The first step in problem solving is always to identify what the problem is, and in the previous section, we covered many of the most common business problems faced by companies. This book does not tell you which platform to choose to address your business problems, but because you’re reading this book, we assume you’ve decided to use MOSS. After a company has made the investment in software to help improve business processes, there is always the immediate rush to try to realize ROI as quickly as possible.
ROI is a common performance measure used to evaluate the efficiency of an investment. To calculate ROI, the benefit of an investment is divided by the cost of the investment; the result is expressed as a percentage or a ratio.
To determine the ROI, it is important to quantify the cost of the problem being solved. For example, if it takes a resource three hours to do a task and that resource makes $10 an hour, then the cost of the task is $30. If you can reduce that task to only one hour, it now only costs $10, or one-third of the original amount. If that same task happens 100 times a day, you would have a cost savings of $2,000 per day or more than $100,000 year.
A very simple example relating to MOSS is to look at the search capabilities. Imagine trying to find a specific document in an organization that stored all of its electronic documents in file shares. You might have to pick up the phone and call someone to help. The total cost of the time spent from the resources used to find the content quickly adds up. Compound that same situation over and over again, and you quickly build a compelling business case where MOSS can provide real quantifiable ROI.
Don’t worry, this book isn’t turning into a lesson on economics. If you never read a single business case, just remember that the key to achieving a high ROI is to invest as little as possible and achieve maximum gain. Imagine if you could work for 10 hours a week and get paid for 40 hours. That would be an example of excellent ROI.
By implementing any of MOSS’s long list of features, you can see a quick ROI, but the key to unlocking the value of the product begins before you install any software. The first step is to ensure that your team can speak to the functionality of the product. Having a solid understanding of MOSS and what it can and cannot do is often overlooked, but it is the foundation for a successful implementation. This doesn’t mean that you need to be the world’s foremost expert on MOSS, but it is important to have an understanding of what the product is capable of doing. Specifically, you need to understand what tasks are possible and the amount of effort required to perform them. This basic product knowledge shapes each aspect of the MOSS implementation to help ensure success. Without it, you run the risk of increasing scope and level of risk.
For example, say you have a MOSS implementation for a manufacturing company, Widget Manufacturing, with more than 1,000 employees at this location. The company has been around for many years and still maintains a large number of paper documents, and its electronic documents are stored in file shares across the organization. The company has invested in MOSS in an effort to update its processes to include document management, content management, business intelligence, and workflow. The long-term vision is to leverage all of the capabilities in the product to help increase productivity and collaboration across the organization.
This scenario is very similar for many companies that are considering implementing MOSS. Whether the company is larger or smaller than Widget Manufacturing, the scenario remains the same: an organization with many paper documents and a number of electronic documents wants to update its processes. Like most companies, Widget Manufacturing is also looking to realize ROI from its investment in MOSS as soon as possible. Now what?
Fortunately, the MOSS implementation team at Widget Manufacturing has received some formalized training, has been reading technical materials, and has reviewed many of the online resources for SharePoint information. Although the team has never done an implementation, it is intimately familiar with what is possible and has an idea of the level of effort required for many of the tasks. With that knowledge in hand, the team begins the process of gathering requirements for the project. While gathering requirements, the team hears a long list of desired functionality that runs the gamut of MOSS’s capabilities. The team collects its notes and realizes that implementing all of the requested features would take well over six months and exceed the planned budget.
The MOSS implementation team discusses the project and comes to the conclusion that simply getting all of Widget Manufacturing’s organizational content into MOSS and familiarizing the employees with how to use a new tool will be a significant undertaking. The team decides on a multiphased implementation, with the first phase to include installing MOSS and configuring the portal structure to meet the needs of the organization while taking advantage of the document-management functionality and search capabilities. The team agrees this can be done relatively quickly and easily. Widget Manufacturing will be able to see ROI from MOSS almost immediately.
The team clearly communicates its goals for the first phase to ensure everyone is aware that this will be the first step in Widget Manufacturing’s plan to implement its vision for MOSS. As an additional benefit, as users begin to use MOSS, it will serve as a foundation for future requirement sessions. The team plans additional phases that will further enhance the capabilities of the product while working toward the ultimate vision.
This example is fictional, but the details are drawn from real world examples. Typically, if this type of model is followed, the implementation is successful, the users are happy, and the MOSS implementation team is happy because it has completed a successful implementation.
Conversely, what if the team decides to try to implement all of the functionality originally requested by the company in a single phase? The team may be able to pull it off, but it will take a lot longer, the risk is higher, and the likelihood for hiccups along the way is also higher.
Because the MOSS implementation team decided it was going to deliver the complete functionality across multiple phases, the key difference between the two approaches is that the multiphased approach allows companies to realize ROI much faster, thus making management happy and achieving business goals sooner. Also, it has the added bonus of letting users get their hands on the products sooner so requirements can be refined as the phases are implemented. The end result is normally a portal that more closely meets the needs of the users.
Out of the Box
The term out of the box is used throughout this book, but what does it mean? If you think of MOSS like a car, out of the box would be the same as “stock.” When you purchase a car and drive it off the lot, there are certain things that it can do. It has a specific amount of horsepower, has a top speed, handles a certain way, has a standard radio that was installed by the factory, and has other basic features. If certain attributes about the car don’t meet your needs, you can change them; however, putting new tires on the car is far easier than changing the engine. For MOSS, out of the box refers to the functionality available when you first install the product. There are certain things it can do quite easily with little effort if you know where to look. In some cases, MOSS won’t meet your needs with the out-of-the-box functionality, and it might require some changes.
Customization Versus Development
A MOSS project is a little bit different than most other projects you are used to. There are subtle nuances to how you’ll perform certain tasks that might take longer than you expected and many tasks that will take significantly less time than you might expect. If you haven’t done a large number of projects, estimating the level of effort required for a MOSS project can be extremely challenging. Your approach to how you deliver the desired functionality to your users will have a dramatic impact on your estimation. With MOSS you have two options: customization and development.
Customization
Customization refers to any changes that can be made via user interface, SharePoint Designer (SPD), or InfoPath that do not require custom programming. This includes the use of the out-of-the-box Web Parts, list and site templates, and all of the capabilities of SPD and InfoPath.
Pros
Quick to implement
Low risk
Cons
Limited functionality
Limited code reuse
No real source control
Difficult to move between environments
Development
Development refers to any changes that do not fit into the description of customization. Generally development is done with Visual Studio and requires custom programming.
Pros
Unlimited options for functionality
Reusable code
Cons
If we think of the car example, customization is the same as options that were available from the dealer; whereas if you decided to overhaul the engine yourself in your garage, that is the equivalent of development. As you can see, both methods have their merit; in skilled hands, putting a new engine into your can be a great thing and have a huge impact on your car’s performance. The fact is that most of us aren’t skilled mechanics, but that doesn’t mean we can’t try to improve our car’s performance—we just have different options.
The key difference between the two approaches lies in the fact that development allows much more flexibility with regard to the type of functionality that is possible. Rather than picking one approach over the other, the best option is to take the best of what each approach has to offer. For example, if Widget Manufacturing had a need for a custom workflow process for an HR form, the company would have to decide how best to deliver this functionality. They could choose any of the following:
Use the out-of-the-box MOSS workflows.
Create a custom workflow using SPD.
Have a developer write a custom workflow using Visual Studio.
By looking at the specific business requirements, you can determine which option will best meet the requirements with the available skills and within the desired timeframe. The rule of thumb should be to choose the option that most closely meets your needs and requires the least amount of effort. For the custom workflow example, perhaps either a workflow with SPD or custom-developed workflow would meet the requirements. With ROI in mind, we should choose the SPD workflow because it takes less time to implement, and the skills are more readily available.
Use the K.I.S.S. Principle
Keep It Simple SharePointer! The simple option doesn’t always seem as cool, but as you’ll learn throughout the following chapters, the simple options are often a lot more powerful than you might expect.
Being able to effectively use the out-of-the-box functionality in MOSS is an important skill that all members of your SharePoint team should familiarize themselves with.