Maybe software should be packaged like this?  Photo: Tetra Pak Package Portfolio, by Tetra Pak, CC license

A “packaged application” is software already built, coded, tested, used by other enterprises in your industry, and hopefully a solution that will meet most of your needs.  In general I recommend using packaged applications (why re-invent something?)

But a packaged application is not ready-to-use, in any sense of the word. The word “packaged” is kind of a misnomer. You won’t find a warehouse management system in a shrink-wrapped box on the shelf at Best Buy. A packaged application is simply one whose features and functions match in general terms what you want the software to do, but which still needs to be configured for your business. Configuration (also called setup) involves a lot of work and expense.

Much of the time involved in configuration is not in setting up all the data and parameters, but in deciding what data and parameters to set up. What data do you want to/have to set up for each customer? Should employees be “suppliers,” so that you can reimburse them for travel expenses? Do you want to manage your inventory levels according to min/max parameters or days on hand, or some other way? In most enterprises, decisions like these aren’t made by one person – groups of people get involved, and all those meetings and explanations have to be scheduled, and someone has to herd everyone into a decision. Not a quick process.

Packaged software is an annuity business. A software company survives in the long run because it is able to collect annual maintenance and support fees from its customers while providing custom development services and a stream of version upgrades. The support fees can be 20% to 25% of the original cost of the software license, so to the software firm, it’s like selling a new system to the same customer every four or five years. In exchange for the fees, the customer gets access to support desks, can have the software firm make modifications to the system usually on a time-and-materials basis, and automatically gets some upgrades and patches (or fixes) as well as user guides and maybe some technical documentation.

Recurring support revenue is highly profitable for vendors selling packaged applications. It is not unusual for big packaged software vendors like SAP, Oracle, and JDA to have this type of revenue represent 60+% of its sales while incurring only 5% or 10% of its operating expenses.

If you are selecting a packaged application, understand that your vendor will try to sell you the traditional on-premise solution, in which you will own and host the software while paying the vendor for additional licenses, upgrades and custom developments, plus the annual maintenance fees of 20% to 25% of the original license cost, which, on a license costing $500,000, for example, would be $100,000 to $125,000 per year.

And therein lies one of the most debated and disruptive topics in the software market today: the move away from the traditional on-premise (also referred to as perpetual license) model to a service or subscription-based model.  It is not exaggerating to say that the perpetual license model has in a way been the drug, the stream of highly profitable revenue, sustaining the software industry the past two decades.  Stay tuned.

Never mind how many people you can get to work on your enterprise software project team. The critical factor today is how much of their focused attention you can get when you need it.

Quoting columnist and Guinness record holder for Highest IQ Marilyn vos Savant, “Working in an office with an array of electronic devices is like trying to get something done at home with half a dozen small children around. The calls for attention are constant.”

It is not easy to get people to pay attention. Your project is competing for share of mind with texts, email and the internet emanating non-stop from your team’s cell phones.

Thomas Davenport and John Beck, in their book The Attention Economy, state: “The ability to prioritize information, to focus and reflect on it, and to exclude extraneous data will be at least as important as acquiring it.”

In 2005, I was on a team whose mission it was to modify parts of SAP to enable the sale and invoicing of what are called “kits.” A kit in software parlance is a product whose components include other products. The final product is what is recorded as the sale and what appears on the customer invoice. Sounds simple, right?

We worked in a global company. The team participants were in Ohio, New York, Western Europe, The Philippines, India, and Texas. After 14 months the team had finally gotten to the point at which it could test the solution. There had been more than 25 full-team conference calls, but no face-to-face meetings in which everyone – business people, developers, and technical experts – was present.

Why did it take so long? Attention deficit: People in remote locations for whom this project was one of many, and whose interaction with the substance of it was via impersonal conference calls during which multi-tasking naturally diverted one’s attention.

Do you know anyone who does not multi-task during a conference call? The attention deficit is automatic. People are caught not listening. Participants tend to speak a lot less than if the meeting is held face to face. It’s easy to hide and withdraw on a conference call.

We pride ourselves for the ability to work virtually across continents, have meetings anytime anywhere, and send work around the globe as if we were passing it across the table. But I think we’ve diluted our effectiveness and the quality of our output. We split our minds into more and more slices, marveling at our ability to manage so many things at once, but all we are doing is giving cursory attention to a lot of things instead of focused energy on a few.

Who needs a methodology?  Just do it.  Photo: Spring 2013 Hackathon at Columbia University, where participants were challenged to build — over a weekend —  software programs for New York City startups; by Matylda Czarnecka, hackNY.org, CC license.

You’re about to launch a big ERP project.

You need a structured methodology.  The lazy/easy thing to do is to use the one your software vendor or consulting partner uses.  Don’t automatically accept this.  Understand first how their methodology works (it’s usually designed to maximize billable hours).  Then use common sense.

A methodology is simply a way of doing things. A methodology for doing laundry could be: 1) separate colors from whites; 2) wash whites in hot water/cold rinse with bleach; 3) wash colors in cold water; 4) hang dry delicate fabrics and put everything else in the dryer on medium heat for 30 minutes.

But there can be variations in laundry methodology depending on preferences and beliefs, such as 1) throw colors and whites together in a cold wash and cold rinse so colors don’t run; 2) throw everything in the dryer on delicate cycle; 3) check periodically for dryness; and 4) pull out anything that seems dry.

IT project methodologies are practically an industry – templates, software, books, training programs and consulting engagements.

The “waterfall methodology” used in Microsoft Project and adhered to for decades by many in the project management field is arguably flawed from the beginning, at least according to some. This methodology assumes that task completion is a function of the number of man-hours, total time duration, and dependency on completion of one or more preceding tasks. Viewed on a chart, the timeline of the project looks like waterfalls cascading from left to right, top to bottom, as time progresses.

Frederick Brooks, the computing legend who pioneered IBM’s System/360 mainframe computers launched between 1965 and 1978, says in his seminal book The Mythical Man-Month that “the basic fallacy of the waterfall model is that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds (but) experience and ideas from each downstream part of the construction process must leap upstream, sometimes more than one stage, and affect the upstream activity.”

Brooks also says the planning process usually and mistakenly assumes that the right people will be there, available, focused and engaged, when they are needed, and that when they perform their work they will do so in a linear fashion, with no mistakes and no need to backtrack and start over. In the 21st century, this is simply not the case in many organizations.

I don’t prefer one particular methodology – I think the way to work depends on what you’re trying to achieve, by when, with whom. I also think the imposition of a particular methodology – if it doesn’t fit the project or the team – will actually detract from success.

I do like at least one part of the Scrum methodology, called a Sprint.  It could be a one week or two week “Sprint,” but the idea is the same: everyone needed for a particular stage or segment of the project is brought together and forced to stay together until their part is finished and tested.  Just get together and get it done.

Have you seen the videos where a house is built in a day?  Here is just one.  How did they do that? Lots of preparation, teamwork, intensity, focus, urgency.

The idea of a sprint in an IT project is the same: skilled people intensely focused on the same, singular objective that must be achieved within a fixed period of time.  I like it because sometimes it’s the only way to get the brains you need to complete something without the endless distractions of everyday work.  Attention deficit is rampant in organizations today — exactly the opposite of what successful enterprise software projects need to be successful.

Which methodology is best? For your project, the best methodology is the one that provides structure in a common-sense way with simple, easy-to-use tools that you think your team will, in a practical sense, actually stick to.

Photo: “Trails in the Sand,” Dubai, by Kamal Kestell, CC license

If “Humanscale” computing is managing bags of sand, “Hyperscale” computing is managing each individual grain of sand in every bag.

“Hyperscale” computing (HC) is the processing of data, messages or transactions on a scale orders of magnitude larger than traditional computing.  HC is becoming a need for many businesses.  Why?

Consider a company that sells bottled water.  Its main business used to be selling truckloads full of cases of water to big grocery chains.  It has 25 different products, or Stock Keeping Units (SKUs).  The big grocery chains then distributed cases of water to its stores, which numbered 20,000.  The data requirements for the water company’s computers was manageable, even as the company grew rapidly.

Now, the company wants to analyze the performance of its products on store shelves by measuring things like velocity (how fast the product turns), price compared to competing products, and out-of-stocks.  It’s customers — the big grocery chains — are offering to supply data from their systems on every scan of every product in every store, because they too want to improve the performance of products on the shelf.

In one month during the summer, about 3.5 billion bottles of water are sold.  A data file from just one big grocery chain runs to 3 million lines.  How and where will you process this data?  Traditional databases will be too slow.  You will need superfast databases that distribute computing to many servers — this is called in-memory, or massively parallel computing.  This is an example of hyperscale computing.

Other examples where you would need HC: selling direct to consumers through their smartphones, where you might have to process millions of transactions say, during the Christmas holiday season; gathering machine data every second to monitor a machine’s performance (a General Electric turbofan jet engine generates 5,000 data points per second, which amounts to 30 terabytes every 30 minutes); and managing millions of product-attribute combinations.

The computing tools for hyperscale will not be found in your ERP system.  Trying to engineer your existing systems to handle hyperscale data and transactions will be a costly failure.  But there are tools available on the market today, and many of them are found in cloud applications, and in application hosting providers.

Cloud application and hosting vendors usually have much larger data processing capabilities, including automatic failover and redundant servers.  You can take advantage of this capacity.  For example, you can obtain, from a leading application hosting provider, at a cost less than the monthly rent of an apartment in New York City, 30 terabytes of storage and a massively parallel computing environment.

My advice:

• Identify areas of your business that are significantly under-scaled, or where you have large gaps in business needs compared to processing capability;
• Pick one and design a pilot project (many vendors are willing to do this with you at very low cost);
• Measure results and benefits, and if beneficial, expand the solution to other parts of your business.

It’s probably not OK to ignore this trend.  Even of you don’t need HC today, think about the future and where commerce is going.  If you don’t gain the capability for hyperscale computing, one or more of your competitors probably will.

Think of the typical meeting in your enterprise: people come in late, sometimes talking on a phone or otherwise distracted, and 10 or 15 minutes are spent getting into the real content of the meeting. Maybe someone asks what the meeting is about. The person who set up the meeting speaks up and may (or may not) explain what is needed from the meeting. Discussions ensue — some are on point to the reason for the meeting; others are irrelevant. Agreement is reached on a few actions and follow-ups, some people have to leave early, and the meeting breaks up.

These norms are anathema to a serious and successful software investment project, which demands rigor and, above all, structure.

Embrace Structure. You need, at a minimum:

• A work plan that is reviewed daily, with tasks, due dates and responsible owners
• System requirements, testing scenarios and future processes that are documented in detail and agreed to by all stakeholders;
• An issue resolution process to ensure that impediments to progress are eliminated;
• Commitments by team members to own and deliver key parts of the project on time;

A sense of urgency and focus are hugely important to success. In the film Apollo 13 – a great drama but also a study in focused, man-plus-technology effort and achievement, about six technicians in a conference room must assemble an air scrubber exclusively from parts that are available on board the returning spacecraft, because the main scrubber in the craft has failed, causing carbon dioxide inside the craft’s cabin to reach dangerous levels.

The astronauts will die – soon — from lack of oxygen if they cannot fix or replace the scrubber.

The technicians jump on the challenge, and produce a prototype that the Apollo 13 astronauts are able to replicate. We witness urgency and focus, and a breakthrough that saves the crew.

Can you imagine any of the technicians in that scene saying, “Hey guys, I’m good for another 10 minutes but then I’ve got another meeting”?

Well, you say, of course no one would say that; lives are at stake. True, but people skipping out of meetings is an everyday occurrence that does inhibit progress; in an IT project the lack of progress – bit by bit here and there – adds up to a late project over budget and potentially damaging to the business.

The average software project is not a moon mission, but it does require the same kind of focused and structured work that such a mission benefits from.