What I do

Posted by Robert Merrill on November 28, 2008 under uFunctional Values | Be the First to Comment

I sort things out. I make do with what you have. I get something done.

I sort things out. From our first no-cost meeting, I’ll be sorting things out, in a curious, non-judgmental way. How does your business work? What software are you running, and where did it come from? Read more of this article »

Comments on the Legislative Audit Bureau report

Posted by Robert Merrill on November 22, 2008 under Uncategorized | Be the First to Comment

(I wrote this back in Summer 2007, but since I went all WordPress all the time, I had to recreate it as a blog post and the date changed).

Nothing I read in Report 07-5 surprised me at all. The problems are well known.

  • Big projects are failure-prone
  • Requirements are hard to understand, and they change with time
  • Early lifecycle estimates aren’t very accurate
  • Pre-existing data is messy
  • Pre-existing software is messy

None of these things surprise or frustrate me any more. Nor do I expect they surprise most software-development professionals.

What frustrates me are the proposed remedies.

  • Better planning
  • More oversight

Like the problems,they don’t surprise me. To quote the American novelist Willa Cather, “There are only two or three human stories, but they go on repeating themselves as fiercely as if they had never happened before.” Calls for better planning and more oversight don’t surprise me. They just frustrate me.

The first one is less frustrating. I’m not against planning. I do it all the time. It helps me focus on the objective, gather my thoughts, and take the first few steps with confidence. But plans do not determine the future. The future just isn’t very cooperative.

The second one frustrates me more. Apparently, Kate Nolan had plenty of oversight. On the same day that the Wisconsin State Journal reported on the audit findings, it also reported that Ms. Nolan, a project manager on one of the few large projects praised by the audit, was
taking early retirement because she was “very, very tired” of fighting “patently ridiculous ideas” from superiors. By and large, software projects don’t need more oversight. They need better oversight. Overseers need to find the trustworthy and the competent like Ms. Nolan, listen to them, and empower them, not burn them out and run them off. And they need to understand and accept that

  • Big projects are failure-prone
  • Requirements are hard to understand, and they change with time
  • Early lifecycle estimates aren’t very accurate
  • Pre-existing data is messy
  • Pre-existing software is messy

You can succeed despite these things, but only if your recipe and criteria for success don’t depend on their not being true.

Learn More

Software project success, failure, estimation, and methodology are fascinating topics, and it’s surprising how little people who ought to know about them, don’t. Here are my top picks:

Lean Software Development: An Agile Toolkit by Mary Poppendieck. Lean manufacturing and product development (think Toyota) applied to software, by someone who’s actually done both software and product development. It’s even a short book!

Software Estimation: Demystifying the Black Art by Steve McConnell. Chapters 8 and 9 of Steve’s Rapid Development are also an excellent introduction to the estimation problem.

What’s a Software-Intensive Business?

Posted by Robert Merrill on under Software-Intensive Businesses | Be the First to Comment

I coined the phrase “Software-Intensive Business” after three decades as employee, contractor, and consultant. I found myself saying, “These folks have backed into the software business, and they don’t know it.”

I think a list of attributes is easier to understand than a formal definition. Read more of this article »

The “Software Factory” Metaphor

Posted by Robert Merrill on under Uncategorized | Be the First to Comment

The “Software Factory” metaphor has been around for a long time–at least 20 years. Now I see it’s become associated with an award-winning book and a Microsoft methodology. It’s no wonder that the Software Factory metaphor is attractive to buyers of software. It calls to mind predictability and low cost.

But what if it’s wrong?

Metaphors create clarity–that longed-for A-HA! Bad metaphors create the illusion of clarity, and cause people, especially managers and executives, to charge ahead, heedless of warning signs, until there’s undeniable trouble. The author of the metaphor may understand the limitations and subtleties, but those get lost, especially when the metaphor is really attractive.

The Software Factory produces software. This metaphor leads to an inward, process-and-cost focus.

Now, predictability-and-low-cost is the Holy Grail of software development, and ever since Fred Brooks, people have been on a quest for the Holy Grail with a gun full of Silver Bullets. People have always longed for the Software Factory, and maybe it’s finally arrived in the book by Greenfield, Short, Kent, and Crupi. (I admit, I haven’t read the book yet.)

Or maybe the predictability and low cost associated with software are really here, already, and we’re just not appreciating them. It’s only natural that we think of the fruit of our own labors, especially if it’s tangible, as The Product. We make software, so software must be the product. But is it?

Drill Bit–or Hole Factory?

Consider drill bits. The last time I bought a drill bit, I didn’t really need a drill bit. What I needed was a hole of a certain size that my hole factory–my trusty Black and Decker–could not produce. So I retooled my factory–literally–and then I could make 9/16 inch holes with abandon, at low unit cost and with a lot more precision than with a mallet and a chisel.

The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.

Now consider software. People buy this product, but they don’t put it on the wall to admire it. They don’t eat or otherwise consume it. They use it to accomplish or experience something. They use it over and over, as they use tools of other kinds, or as a company uses a factory. Garbage goes in, and altered garbage comes out, but quickly and (usually) predictably. Sometimes it lets them do things they already could, only faster and with fewer errors. And it lets people do things that weren’t even possible before, or that were prohibitively expensive and time-consuming without computers. We’re surrounded by low-cost, predictable information access and experiences. Low-cost, predictable things come from factories–in this case, from computers controlled by software.

What if the Software IS the Factory?

A Tale of Two Metaphors

Consider where these two metaphors lead us.

The Software Factory produces software. This metaphor leads to an inward, process-and-cost focus.

The Software-As-Factory produces a user experience. This metaphor leads to an outward, experience-and-value focus.

Now, it isn’t that the Software Factory can’t produce high-value software that creates great user experiences. It’s just that it tends to lump those concerns in with factory-floor concerns about getting the product–the software–out the door, at minimum cost. Usability and value become second-order attributes of the product.

The Software-As-Factory metaphor separates concerns more cleanly. We want to produce a valuable and delightful user experience–the end product–reliably and at low cost, and for that, we need a factory. Maybe we can retool an existing factory, or maybe we will need to build a new one. Will there be just one factory–a hosted application–or will there be many locally-operated factories–a shrink-wrap application? Does the factory produce a single product, or a variety? If a variety, the factory itself might be complex to operate and require special skill and training.

Notice that the Software-As-Factory metaphor encourages us to see past the increasingly artificial business-technology divide. There are people who use the products of factories–the user experiences–as is. Some of them learn to retool the factory to produce a short run of a customized experience for the use of a smaller number of end customers. Think of the office Excel whiz. Finally, there are the people who design and build factories–professional, full-time software developers. Maybe they are the Industrial Engineers of the information-technology world.

Product Manufacturing versus Product Development

Under the Software-As-Factory metaphor, software development is more like product development than product manufacturing. This is not my idea. Mary Poppendieck quotes Kosaku Yamada, Chief Engineer of Toyota’s Lexus line, “The real difference between Toyota and other vehicle manufacturers is not the Toyota Production System, it is the Toyota Product Development System.” In other words, the Toyota advantage isn’t that they run great factories (though they do). It’s that they conceive of great products, and implement the factories to make them, better than anyone else. Mary Poppendieck also cites 3M (where she spent a good portion of her career) as another example of product development excellence.

Now I’m fired up to go learn more about the Toyota Product Development System and how that relates to the Software-As-Factory metaphor. I also need to read Software Factories because it is well reviewed and I’m sure I will learn a lot from it.

But the idea of a software productivity breakthrough, as opposed to a welcome yet still incremental improvement, through software development tools? Not if the software is the factory and not the product. Call me skeptical.

Recession: A Quiet Opportunity for your Software-Intensive Business

Posted by Robert Merrill on under Uncategorized | Read the First Comment

(I wrote this in March 2008, but since I went all WordPress, all the time, I had to recreate it as a blog post).

Here we go again. The high-flyers are belly-flopping, and the rest of us get soaked. It’s recession time.

Whether out of necessity or knee-jerk reaction, a lot of software-intensive businesses are going to be letting software contractors and employees go in an effort to cut costs.


The direct effect, obvious to everyone, will be downward pressure on hourly rates and salaries for software professionals. If the tech crash of the early “oughties” is any indication, larger consumers of software resources are going to use the opportunity to lock in lower rates with their vendors and hold firm on raises for their employees. They’ll benefit from the savings due to reduced headcount, plus slightly lower unit costs. They’ll reduce capacity, put a few more projects on hold, and work everyone else a little harder. Belt-tightening and cost-cutting—that’s the obvious response of the software-intensive business to the recession.

“The quiet opportunity of the recession will be on the productivity side of the equation…”

The indirect effect, however, will be a richer talent pool. It’s just my perception, but unlike the 90’s boom, salaries haven’t skyrocketed in the 00’s, and software professionals have tended to stay put rather than trading up.Out of panic or necessity, some companies will break up some truly fine software teams. Some of those people will now be on the market. Hence, the opportunity.

Good People

Good people tend to attract good people and form good teams, and good teams are more productive. Software productivity is harder to measure than cost, but it’s also a lot more variable. The difference in productivity between a weak team and a strong one is at least two to one especially on small to medium projects. And productivity—the cost to produce an “ounce” of software—is only half the story. More effective software organizations also produce more useful software per ounce—fewer features that never get used, and more features that really help the business—through the better governance, better user involvement, and better processes that tend to follow good people.

If your software-intensive firm has the means, a recession is a great time to strengthen your software-development capability through thoughtful recruiting.

I’ve heard it said that out of chaos comes opportunity. For the software-intensive business, the quiet opportunity of the recession will be on the productivity side of the equation, not the cost side.

A Note on Programmer Productivity

Posted by Robert Merrill on under Estimation | Read the First Comment

In Recession: A Quiet Opportunity for your Software-Intensive Business, I suggested that the productivity gains from improving your team far outweigh the cost savings possible in a buyer’s market for talent.

Just how variable is programmer productivity, anyhow?

Person-to-person and same-person variability

If you give a group of people the same programming project, how long does it take them? How much does an individual’s productivity vary from task to task?

As Sherwood (2006) says clearly, “I have found it surprisingly hard to find good academic literature that measures productivity.” She quotes the following ranges:

  • 28:1 best to worst (Sherwood 2006a, citing Sackman et al. 1968)
  • 22:1 to 8:1 best to worst for two problems, depending on how you treat the outliers (Sherwood 2006a, citing Curtis 1981)
  • 3:1 to 2:1 best to median for two problems (Sherwood 2006a, based on Curtis 1981 data)
  • 4:1 to 2:1 best to median (Sherwood 2007, citing DeMarco and Lister 1985. The latter also found that productivity was correlated with the organization that programmers came from, even though they worked independently during the study).
  • 2:1 best to worst (Sherwood 2006b, citing Ko et al. 1996)

Spolsky (2006) quotes another range:

10:1 to 5:1 best to worst (Spolsky 2000, based on several years of student project data from a computer science professor at Yale)

Project to project variability

My own project metrics over a period of about five years show:

  • 20:1 best to worst project productivity (largely the same people, in different teams, using different technologies to implement various web application projects. Some were all-custom, and others were customization of commercial or open source software).
  • 3:1 difference between productivity on two projects completed by the same developer using the same technology

The COCOMO II estimation model (Chulani et al. 1997) has adjustment factors for total project effort based on personnel attributes by role:

  • 2.25:1 best to worst analyst
  • 1.85:1 best to worst programmer
  • 1.5:1 most to least familiarity with the application domain
  • 1.5:1 most to least familiarity with the technology in use


There is a lot of variability. No wonder estimation is difficult. Here are some principles about productivity from the above.

  • Productivity probably varies within a given organization by at least 2:1
  • Individual productivity varies from task to task, probably by an equal amount of 2:1
  • A team is more than the sum of its parts. Analysts have the highest leverage; analyst capability swings productivity by over a factor of two, even though they directly contribute maybe one-fourth the effort (my rule of thumb).
  • Project productivity, based on individual capability, team capability, familiarity with the domain and the technology, and the technology in use, easily varies by 10:1.


Chulani, S., B. Clark, and B. Boehm 1997: Calibration results of COCOMO II.1997. 22nd Annual Software Engineering Workshop, NASA Goddard Space Flight Center.

Curtis, B 1981: Substantiating programmer variability. Proceedings of the IEEE, 69, 846. ISSN 0018-9219.

DeMarco, Tom and Tim Lister 1985: Programmer performance and the effects of the workplace. International Conference on Software Engineering, 268-272. ISBN 0-8186-0620-7.

Ko, A., Myers, B. A, Coblenz, M. J. and H. H Aung 2006: An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks. IEEE Transactions on Software Engineering, 32, 971-987.

McConnell, Steve 2006: Software Estimation: Demystifying the Black Art. Microsoft Press, 308 pp. ISBN 0-7356-0535-0.

Sackman, H., W. J. Erickson and E. E. Grant 1968: Exploratory experimental studies comparing online and offline programming performance. Communications of the ACM, 11, 3-11. ISSN 0001-0782.

Sherwood, Kaitlin Duck 2006a: Don’t get stuck, a review of Sackman and Curtis. http://www.webfoot.com/blog/2006/12/07/programmer-productivity/.

Sherwood, Kaitlin Duck 2006b: Review of Ko’s “An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks.” http://www.webfoot.com/blog/2006/12/15/programmer-productivity-part-2/.

Sherwood, Kaitlin Duck 2007: Review of “DeMarco and Lister’s Programmer performance and the effect of the workplace.” http://www.webfoot.com/blog/2007/02/16/demarco-and-lister/.

Spolsky, Joel 2000: Hitting the High Notes. http://www.joelonsoftware.com/articles/HighNotes.html

Buy, Build, and Beyond

Posted by Robert Merrill on under Uncategorized | Be the First to Comment

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.

Sofware Program Planning and Implementation at a Complex Non-Profit

Posted by Robert Merrill on under Client case studies | Be the First to Comment

A uFunctional LLC Client Case Study


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 and the three replacement Access databases
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.


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.

Context Diagram of the legacy LPP system
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).


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.


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.

All WordPress, All The Time

Posted by Robert Merrill on under Uncategorized | Be the First to Comment

That’s the new and improved www.ufunctional.com.

I did this myself, design and all, because:

  1. I want to stay sharp and I don’t have any programming projects right now, and
  2. I’m watching my cash flow.

Don’t get me wrong, I’m spending more money on marketing than ever, including around $1000 to Read more of this article »