Posted by Robert Merrill on November 22, 2008 under Uncategorized | 
Understand both approaches
There are better lists of pros and cons than I could make. But here are three things I think get overlooked or ignored.
It’s harder to get the requirements right than you think
First, “Prediction is really hard, especially about the future” (thanks, Yogi). Your competition does something, or senior management has a change in strategy. This probably won’t affect your email, it may affect your CRM and ERP, and it will almost certainly affect your ecommerce site.
Second, you don’t control all of your requirements. Regulations, new partnerships, and mergers and acquisitions can all invalidate what really was the best choice of software at the time..
Customization of purchased software is usually a bad idea
Everybody knows this, but it’s oh-so tempting. And the vendor’s margins are better on services than products anyway.
“If you need to modify more than 20% of a software product, it’s probably cheaper to build.”
The rule of thumb I’ve heard and followed is, “If you need to modify more than 20% of a software product, it’s probably cheaper to build.†This is especially true when you consider rolling those changes forward across upgrade cycles.
The best way to succeed with commercial software is “don’t fight it.” Use it the way it comes, or with common configurations and extensions only.
And accept that “It’s harder to get the requirements right than you think.”
Either way, it’s all about the people
When it comes to the crunch—new requirement request, problem, or upgrade—you are going to need a person who knows the software, as you‘re using it. Failing that, someone needs to become that person. That will take access to information, and time. Neither is guaranteed to be available.
If the software is critical or complex, you need a vendor or channel partner with competent and trustworthy people who are allowed to talk to you. If you built, the same is true of your development organization, whether internal or external.
See past the immediate decision
The object of the game is deceptively simple. Maximize total value across all of your spending on software. That means making individual choices that solve the problem at hand, without reducing the value of your whole environment.
TCO, not just initial cost
Most people seem to have grasped this. The TCO (Total Cost of Ownership) concept is valuable because it looks beyond the initial purchase or development effort. Before a buy, consider maintenance fees and upgrade path. Before (and during) a build, focus on software quality and maintainability in addition to time-to-market and development costs
TVO, not TCO
“TCO is only one side of the value equation.”
But TCO is only one side of the value equation. There’s also a benefit side, and you need consider which is most important when it comes to a particular system. With reason, companies tend to think differently about their email than they do about their retail ecommerce site, even though they’re both “software.†Think Total Value of Ownership, not just TCO.
Know thyself
Know your own firm’s ability to execute either strategy.
Either can be executed well or badly. The choice is never between the ideal buy and the ideal build. It’s between
- the software on the market and how well it can be deployed in your environment, and
- the software your organization is actually able to build with the people you have to work with.
The “wrong†strategy, executed well, may yield better results for your company than the “right†strategy, executed badly.
If the product and vendor market is weak, that may favor a build.
If your procurement organization is good at buying durable goods, not software, or is easily dazzled by a demo and a fancy lunch, that may favor a build. (I’ve heard that software vendors typically spend over half of their budget on sales and marketing).
If your organization’s track record at building applications of this size is poor, or unknown, that favors a buy. Notice the phrase “of this size.” Big projects are different—and riskier—than smaller ones.
Over time, you will probably be doing both building and buying, so it’s worthwhile looking at how you do both, and getting better at each.
Beyond Buy versus Build
Done right, building gives you flexibility and control, now and in the future.
Done right, buying gives you cost savings and reduced time-to-value.
In the last five years, a third way has begun to emerge—customized open-source applications.
“This ‘custom where it counts’ approach can tip the scales back towards building.”
If you face uncertain requirements and have access to an effective software team, this “custom where it counts” approach can tip the scales back towards building.
eCommerce experience
From 1997-2006, I worked for a Madison-area eCommerce firm. We started out building, because the market was so new, and because we sought (and were sought by) clients that were “up to something.”
By the late 1990s, there were many eCommerce packages and services available. We used two of the larger ones and were frustrated by their complexity and limitations. Ecommerce clients want, and need, fine-grained control over their requirements, and it was frustrating to run into one of these “brick walls in the fog.”
After the crash, we returned to market with a new offer—“custom where it counts” based on either osCommerce (LAMP-based) or Open For Business (Java-based). Clients could spend their development dollars on what mattered most to them. For one, it was cutting-edge design. For another, it was a complex pricing structure. For a third, it was configurable product kits.
Open-source application availability
There are now open-source applications in categories besides eCommerce. For example:
- ERP–Open For Business (the first end-user application to be brought under the umbrella of the respected Apache Group), and Compiere
- Web Content Management: Joomla! and OpenCMS
- CRM—Sugar CRM
Compared to building, customized open source:
- Speeds time to deployment
- Reduces development effort
- Reduces risk of a completely failed project
- Offers support resources outside your own team
Compared to buying, customized open source
- Is easier to evaluate—there are no secrets
- Gives you requirements and integration flexibility, now and in the future
- Offers support resources outside of a controlled vendor-partner ecosystem
The market is moving to address some of the weaknesses in documentation and training materials for users and developers.
As with building and buying, having access to trustworthy and competent people who know the software, and know how you are using it, is key.
But developing “custom where it counts†software from an open-source application combines many of the advantages of both building and buying. The drawbacks are that your developers don’t get to code up user login screens, and there’s no sales person to take you to lunch.
Posted by Robert Merrill on under Client case studies |
A uFunctional LLC Client Case Study
Situation
In Spring 2007, the Archdiocese of Milwaukee (ArchMil) and Saint Francis de Sales Seminary (SFS) were beginning a major re-organization. Some organizational processes were being eliminated, others consolidated, and still others moved to units that did not yet exist.
The IT staff of ArchMil and SFS is responsible for infrastructure and utility applications–network, file and print, and staff desktops including productivity applications and email. Scattered custom applications were created and maintained by organizational units to serve their own purposes. This approach to IT governance is fairly common.
One such application was an Access database, developed over a period of about ten years by SFS staff and various contractors. Different people knew and used different parts of it, but no one knew it all.
“Robert Merrill has been a pleasure to work with. I found him to be very insightful and thoughtful in his work. I was pleased that he talked through situations and suggested solutions that he believed would truly fulfill our needs while always looking at the cost/benefit factors.”
Chris D’Amato, Accountant, Saint Francis de Sales Seminary
The coming organizational changes required that this application and its data be divided. In addition, it had a large maintenance and enhancement backlog.
ArchMil and SFS are long-time clients of Northwoods Software Development, of Brown Deer, WI. The ArchMil Intranet and Extranet run on Northwoods’ Titan platform. Northwoods specializes in larger projects, but the SFS database appeared to be a small project, wrapped in a complex context. Northwoods wanted someone who could cover all roles, from high-level software program planning down to Access remediation, refactoring, and new work, so they brought in Robert Merrill, Principal of uFunctional LLC.
Creating a Roadmap
Robert’s first step was to review the SFS Access database with its primary users, determine what functionality was actually being used to support what processes within SFS, and infer dependencies from the underlying data. In requirements interviews, people naturally focus on the primary functionality. When breaking a system apart, it’s important not to overlook dependencies that individual users may not even be aware of. Robert uses Function Point Analysis (FPA) to detect these quickly. Though primarily for quantifying scope and estimating projects, FPA verifies completeness of functional requirements as a side benefit.
Robert then reviewed the primary functions with ArchMil and SFS leadership. Which processes were staying put? Which were moving elsewhere within the organization? Which were shifting to the new John Paul II Center? What pieces of the SFS Access database needed to go where, and by when?
Visual representation of something this complex is vital, so Robert prepared a tablecloth-sized Roadmap, consisting of a series of Phases (organizational states) with intervening Transitions (information system changes).
Roadmap for the SFS Access Database (white, at left), and the three replacement Access databases. Two of them (Transcripts and Deposit Transmittal, shown in gray) remained within the Seminary, while the third (MFI Database, blue) was extracted and enhanced to support a new organizational unit within the Archdiocese. The roadmap was revised regularly—this version is from Transition B planning.
Planning the Transitions
The original Seminary Access Database spanned a large functional scope. The roadmap made it easy for Robert, and ArchMil and SFS leadership, to divide its functions into four categories:
- Functions not presently being used
- Functions supporting organizational processes that were about to cease
- Functions supporting processes remaining within SFS
- Functions supporting ongoing processes being transferred outside SFS
With this information, the three replacement applications shown on the roadmap practically scoped themselves.
Implementation
Because Robert did the functional analysis and was involved in all planning, no handoff to a technical person was needed, and implementation was straightforward and efficient.
Robert and the three affected organizational units selected an agile delivery methodology, with Robert presenting running software with new features every week, and Archdiocese and Seminary staff verifying the correct operation of the new features, and clarifying requirements and providing examples for the next set of features on the list.
“After reading the case study I realize it was the smallest part of your ArchMil work but I always felt you gave it importance, and never let it drop off the to do list. You always worked on the CFC project and came back with revisions for me to review. I have worked with other programmers who only worked on the squeaky wheels. It was refreshing to see your weekly e-mail and know that work had been done. Thanks!”
Cris Hauck, Accountant, Archdiocese of Milwaukee
Near the end of the project series, another Archdiocese group came forward with a fourth project–remediation and enhancement of a small application based on an earlier version of the Seminary database. Robert’s growing experience with the Seminary, the Archdiocese, and the old database made this implementation go quickly as well.
A Supporting Role
As noted above, Northwoods specializes in larger projects. By Spring 2008, one of these was getting underway at ArchMil–a rewrite of a thirty-year-old pension system called LPP. Because of Robert’s expertise with early-stage project estimation, Northwoods involved him in the initial meeting about LPP requirements. Rather than interviewing subject-matter-experts and management independently, Robert led the whole group of about a half-dozen people through a two-hour facilitated session, which produced a functionality context diagram of LPP, on poster paper taped to the wall in the meeting room.
Model of the functionality (white) and referenced and maintained information (yellow) of the legacy LPP system. The functional scope boundary is shown in red. Potential scope enhancements are shown with dashed red lines. With Robert’s facilitation, the users of the LPP system and their manager developed this model in about two hours.
“Your development of the map of the LPP system was well-done and allowed the project to move forward quickly. We very much appreciated the skills you brought to our projects and the significant contributions you made to the success of the projects.”
John Marek, Chief Financial Officer, Archdiocese of Milwaukee
From this model, Robert was able to prepare a Function Point count and initial estimate for the rewrite.
Robert was then asked by Northwoods to work with the maintainer of the legacy system to extract and characterize the subset of data which would be needed to develop the replacement. Using the data-mapping capabilities in Access, Robert developed a largely automated extract-and-transform tool that allowed ArchMil subject matter experts and the Northwoods design team to verify that the necessary data were present and that the business rules were properly understood. The Northwoods team then quoted and completed the rewrite, with Robert’s assistance with data ETL (Extract, Transform, Load).
Summary
On large software projects, it’s common to support the programming team with specialists—project managers, business analysts, and database administrators. Their work is often preceded by that of an application development manager or CIO—someone who is able to work with the organization’s executive team to develop a software roadmap to support organizational change.
“Personally, I appreciated your ability to listen to what I as management required in terms of utility; to hear the functionality that the office staff required in order to input/access data, and the knowledge and wherewithal you used to integrate the two. We got what we needed, the way we needed it!”
Deacon John Ebel, Director of Diaconate Formation, Archdiocese of Milwaukee
This case study is intended to illustrate uFunctional’s ability to provide small projects with the support of these multiple roles, because of Robert Merrill’s diverse background and broad range of skills.
Acknowledgements
Robert would like to thank the management and staff of the Archdiocese of Milwaukee and Saint Francis de Sales Seminary for their willingness to contribute to this case study, and for their essential roles in making this program a success.
Robert would also like to thank Northwoods Software Development for entrusting him with a central role with one of their oldest and most important clients, and for their permission to write and publish this case study.
