But based on my own experience, I know that data organization and management—good or bad—can mean the difference between success and failure.

My professional history isn’t in custom software, it’s in political campaigns. And even though there are complex strategies, in-depth communications plans, and numerous laws regulating campaigns, it’s best to think of them as data collection and utilization efforts for this exercise. Campaigns at the highest levels utilize and generate massive amounts of data, but even small campaigns can run into trouble if they don’t properly manage their data.

To explore the importance of data in both campaigns and business, we’ll look at the three stages of data in a fictional political race and the distinct database management solutions that accompany each of them. This week’s blog will focus on pre-campaign data gathering, though you could just as easily tell the same story about a business expanding into a new market.

The Campaign

Jane Smith has decided to run for City Council. She’s a long-time member of her community, the president of her neighborhood association, and a passionate advocate for her city’s parks. Jane has a great personal network of friends who have promised to donate and volunteer on her campaign. She’s also been lucky enough to be endorsed by two sitting council members, and they’ve each agreed to share their donor and volunteer lists with Jane’s campaign.

In addition to these private data sources, Jane has requested the list of voters who signed petitions for a recent ballot initiative to increase funding for the City’s parks. She rightly assumes that these voters will be supportive of her pro-parks message and hopes to ask for their votes, their donations, and their service as volunteers.

The Database

Knowing that campaigns move quickly, Jane decides to centralize all of her data in a single database. The basis for her system will be the publicly-available list of voters in her community from her local Supervisor of Elections, but Jane plans to customize the pre-existing data with the other public and private data sets she’s gathered.

When done manually, the process of integrating different data sets can be very time consuming. Thankfully, custom software solutions like the ones designed by Octopus Technologies , Inc. can expedite the process. Either way, combining your disparate data sets using a unique key—in this case a voter ID number—will reduce confusion once you begin utilizing your database.

Ready to Run

With her database ready to go, Jane begins planning for her campaign kickoff speech and rally. In the business world, this would be the equivalent of a grand opening celebration: the moment where the rubber hits the road.

In the coming months, Jane and her campaign will be tested in many ways. Some of the obstacles they’ll encounter can’t be predicted, but others are not only predictable, they’re avoidable. Data management mishaps fall into that final category. I hope you’ll come back next week as we explore how effective database management can contribute to happier volunteers, more effective fund raising, and more efficient voter contact operations.

Why Does this Matter to Me?

At this point, you’re probably asking yourself how this applies to you and your business. Great question.

Any business that’s looking to expand to a new market, grow in its current location, or run more efficiently can benefit from the lessons of Jane’s pre-campaign organizing. While you may not have access to a publicly-available list of your likely clients, diligent research can help identify potential new competitors, illuminate an area’s demographics, or streamline an existing sales system. Even existing businesses can benefit from stepping back, reorganizing their data, and re-launching a more efficient system.

Elevate your business with strategic data management! Just as in political campaigns, effective data organization is crucial for success. Explore custom database management solutions with Octopus Technologies to boost efficiency and achieve your business goals. Consult us today!

Guest contributor:  Garrett Garner

The post Database Solutions: A Campaign Perspective (Part 1) appeared first on InTune.

Jane will use her voter database throughout her campaign, but we’ll explore a few specific examples below so you can see exactly how smart database management solutions can make life easier in a fast-paced environment.

The Goal

The goal of any political campaign is simple: winning. And while there are many variations on what it takes to win—think George W. Bush winning the Electoral College while losing the popular vote in 2000, or Bill Clinton being elected with just 43% of the vote—in this case we’ll assume that Jane needs to exceed 50% of the vote in a two way race to claim victory.

Based on past turnout, Jane has calculated that she’ll need 1,000 votes from the voters in her city to be elected. Utilizing her custom database, Jane will work to identify her supporters and opponents, persuade undecided voters, and turn her supporters out on Election Day in order to secure the 1,000 votes she needs.

The Kickoff

Since parks will be a central focus of her campaign, Jane decides to hold her campaign kickoff in a park near her home. Wanting an early show of support in the local news, Jane calls through a list of her friends and neighbors to tell them about her campaign, ask for their support, and (if they’re supportive) ask them to attend her campaign kickoff.

This is an important moment in Jane’s campaign because it has the chance to set the tone for how she will manage her data. Jane probably jotted down her call list from memory and with a little help from her phone’s contact list. But the information Jane gathers during her calls should be entered into the custom database she built before launching her campaign.

Custom databases can be powerful tools, but only if they are correctly maintained.

The Race

Throughout her campaign, Jane will add and utilize many different data sets to her preexisting database. I’ve outlined just a few of them below:

• After her announcement, Jane received calls and emails of support from many of her friends. In answering these friends’ calls and emails, Jane wisely added their names to her list of supporters in her custom database.

• Often, the same friends who are willing to donate money to your campaign are the same ones who are willing to volunteer. Jane would be smart to make both asks during her call time and track the answers she receives in her voter database.

• As Jane’s campaign gains momentum, the types of phone calls being made and the people making them will increase.  In an ideal world, a candidate would talk to every voter in his or her district before Election Day, and—given the size of her community—Jane may be able to accomplish this feat. But it is very likely that volunteers will join Jane’s effort in making calls to determine who a voter is supporting, to ask supporters for money, and to recruit additional volunteers. With so many different types of calls in the field at once, it would be very easy for a voter to receive multiple calls for different purposes in the course of a single week. Thankfully, well-maintained database management solutions can help avoid this problem.

The Final Step

So what’s the point of all this data? Getting your voters to the polls!

The run-up to Election Day (including Early Voting) is known as Get out the Vote, or “GOTV” for short. It’s not C-SPAN’s younger, lesser-known brother. It’s how you win elections. I hope you’ll come back next week as we explore ways to leverage the data you gather throughout a campaign to increase your chances of victory.

Why does this matter to my business?

Just like Jane, businesses receive—or have the opportunity to receive—massive amounts of data on a daily basis.  But gathering data is only half the battle. The two most important questions to ask about data are “Is it relevant?” and “Can I integrate this information with what I already know in order to make smarter business decisions?” Thankfully, InTune, Inc. has experience working with businesses from many different backgrounds to answer these questions and design custom database management solutions to fit your needs.

Guest contributor:  Garrett Garner

The post Database Solutions: A Campaign Perspective (Part 2) appeared first on InTune.

This week we’ll take a look at how everything comes together during the Get out the Vote (GOTV) phase of a campaign. Elections are unique in that they are generally winner-take-all contests, but businesses can learn many lessons from the strategies at the heart of any good GOTV plan.

Trusting Your Data

Your GOTV plan is only as good as the data it’s built on. I learned this lesson the hard way during a race I worked a few years back.

A third party group had made voter identification calls in support of the candidate I was working for, and the data we got back from the calls looked great at first glance. Unfortunately, their coding system conflicted with ours, and when we combined the two data sets and began using the new data points in the field, problems quickly became apparent.

All of a sudden, our team was contacting voters who were unlikely to support our candidate. These voters were coded as “Strong Supporters” in our system, but were from an opposing ideological stance on the political spectrum. The calls and conversations at these voters’ doors did not go well.

What Happened?

So how did we get ourselves into this mess? Simple: the code we used to denote strong supporters was the same code this third-party group used to identify voters who either a.) refused to talk to the person making the phone call, or b.) were supporting our candidate’s opponent.

Once we identified the problem that created issues in our data, we simply back tracked to the last time our list was clean, re-coded the third party’s data, and re-combined the lists. But even though the problem was easy to fix, we’d lost precious time during the final days of the campaign.

So what’s the lesson here? Always, always, always be careful with your data.

Back to Jane

This story isn’t about me, though. It’s about Jane.

Thankfully, Jane and her campaign made it through the identification phase of her campaign without any data coding errors. As Election Day approaches, from her database she pulls a list of voters who are identified supporters of her campaign, but unlikely to vote based on their past voting history. These are the voters the can make the difference between victory and defeat, and they will be receiving the bulk of Jane’s attention heading into Election Day.

Election Day

As Election Day dawns, Jane feels confident. She knows that she’s done everything she can to be assured of victory, including meticulously collecting the data from her conversations in her custom database management.

Jane spends the day calling voters who are unlikely to vote to encourage them to vote and offer them rides to the polls. The results sound promising. Even though she can’t convince all of them to get out to the polls, many of them tell Jane that they’ve already gone and voted for her, or that they have a plan to do so later that day. Jane is cautiously optimistic.

At the end of the day, Jane is exhausted but hopeful. As results begin to roll in, it becomes obvious: she won!

Why does this matter to my business?

As I said before, campaigns and business differ in many ways, but there are lessons they can learn from each other.

If you’re about to launch a new product, open a new location, or host a major retail sale, the behind-the-scene mechanics used to increase your chances of success are very similar to a campaign’s GOTV process. Gathering reputable data and storing it with the help of a custom database (like the ones Octopus Technologies , Inc. has decades of experience building) can mean the difference between successfully communicating with likely customers, and wasting your money talking to people who don’t want or need your product.

Elevate your business with strategic database management! Just as in political campaigns, effective data organization is crucial for success. Explore custom database management solutions with Octopus Technologies to boost efficiency and achieve your business goals. Consult us today!

In the end, it’s all about trusting your data, and trust—in this case—is built on strong custom database solutions.

Guest contributor:  Garrett Garner

The post Database Solutions: A Campaign Perspective (Part 3) appeared first on InTune.

In both business and politics, understanding why a certain outcome occurred is a critical part of ensuring that you can replicate that outcome (or avoid replicating that outcome) in the future. Did your big sale of the year bring in the new customers you wanted? Did a new branch of your company fail? Digging into your data can often help you figure out why.

A Local Example

A friend of mine is an elected official who ran (and won) two data-intensive campaigns for public office. During his first campaign, he knocked on every door in his district and had direct conversations with the voters who lived there. He did this not once or twice, but three times over the course of his campaign. Smartly, he captured the data from these conversations in a custom database management solution.

My friend’s database also included information from his donors. Between the general election and runoff election, donors were able to contribute up to $500 to his campaign, and many people did.

After a victory that was attributed to my friend’s hard work at the doors in his district (and the way he managed his data from those conversations), my newly-elected friend decided to look through the publicly-available data from the supervisor of elections to see exactly how he had achieved his victory.

What he found was startling.

Identified supporters – some of whom had donated the maximum amount to my friend’s campaign – had neglected to vote. Simply knowing this fact allowed my friend to engage with these people throughout his next three years in office to ensure that they voted in his re-election campaign.

Sometimes, even when things go well, your data can point the way to a more efficient future.

A National Example

Former President George H.W. Bush was renowned as a sender of holiday cards. The President’s list began when he and Barbara were first married, but grew quickly as Bush traveled the country in his various jobs. By the time Bush was elected Vice President, the list had grown to the point of requiring a special line item in the Republican National Committee’s budget. By 1983, it had been cross-indexed into an early IBM database management solution.

According to Richard Ben Cramer’s epic recounting of the 1988 Presidential race in What it Takes, the then-Vice President’s wife and staff would begin addressing cards by hand in May to ensure that they were completed in time to be sent out for the holidays. This was a big task, since by 1986 there were over 30,000 names and addresses on the list.

For President Bush, his holiday card list was a chance to keep in touch with friends from years past and ensure that future possible supporters felt a personal connection to him. The strategy worked, and in 1988, Bush secured the Republican nomination and, eventually, the Presidency. A failed attempt to become President in 1980 had laid the foundation for Bush’s later success, and custom database management played an important role in transforming failure into success.

Jane’s Last Hurrah

Thanks to her custom database, Jane was well-positioned for victory. By starting early and tracking her data relentlessly, Jane increased turnout in her own neighborhood and secured a lion’s share of the vote.

In other areas, Jane didn’t do as well as she had expected. With this fact in mind, she plans to target her constituent-service efforts in the areas where she needs to improve her standing. As an elected official, she’ll have plenty of time to convince the voters throughout the city that she’s working hard on their behalf!

How does this apply to my business?

Smart business decisions are rooted in experience and good data. The same is true of campaigns. Both are complex systems, but can be broken down into a series of individual decisions. The effects of those decisions can then be tracked in a custom database and future strategies can be altered based on the data you gather.

Explore custom database management solutions with Octopus Technologies to boost efficiency and achieve your business goals. Consult us today!

Guest contributor:  Garrett Garner

The post Database Solutions: A Campaign Perspective (Part 4) appeared first on InTune.

After completing steps one through five of the eights steps to creating computer system specifications, you may be thinking, “Too much information!” And you’re right. A good specification includes a lot of information, and it takes a significant investment in time to create it. As a general rule, if the business process is clearly defined, and you’re working with a knowledgeable person (or team), you can answer all the questions about one or two screens or functions per hour. If the system includes a number of screens with similar data, and the screens all work the same way, you can define more than two screens per hour.

However, if you’re working with a team that is changing and improving the business process while defining the requirements for a new system, you’ll be lucky to complete one screen per day. Whether the business process is well-defined or not, unless the system is extremely small (less than six screens and functions), don’t expect to complete the requirements gathering in one meeting. After gathering information, you will need more time to document requirements and draw sample screens.

When a clean document is ready, it goes to the business team for review and comments. Plan for this to be an iterative process, because few of us are able to accurately capture 100% of what someone else says. Expect multiple versions of a document before there’s consensus on its accuracy. Don’t underestimate the time required – for both the specification writer and the business team.

7. Don’t assume a specification is complete.

A specification is only “final” when the code is delivered and the client says, “We’re done.” However, unless your system is small and a specification can be completed in a week, don’t wait for a “complete” specification before coding.

A more realistic approach is to identify all the modules or groups of screens that will be in the system, and then work on completing the specification one module at a time. Write the specification for the screens and functions for the module, get client approval, and then hand it off to the development team to begin coding while you and the client begin documenting the next module.

We recognize the risk involved in this approach. Changes requested when the third module is delivered may require developers to modify code delivered with modules one and two. A good development team will plan for this type of change and structure code to make it as painless as possible. Even if the specification is supposedly complete before coding begins, as prototypes are delivered, the client will make changes.

No matter how well you define requirements, how clear the process is, and how lovely the paper screens look, when people actually begin to use the system, they will come up with new ideas. Don’t be surprised when they also find holes in processes everyone thought were complete and problems with assumptions that seemed sound on paper.

Unfortunately, waiting for a complete specification before starting to write code extends the project timeline without significantly decreasing the probability of changes to previously delivered code. In fact, delivering screens, even those with minimum functionality, early in the process allows clients to use the system and make decisions that can be incorporated into specifications for modules that haven’t been coded yet.

Plan for change and document it so the specification reflects the actual system.

8. Get a return on your investment with a clear specification.

If the spec is never final and it keeps changing, why bother with all the work? A good specification:

• Gives the client documentation about what they’re going to get.
• Minimizes the time a client has to spend answering questions about how the system should look and work throughout the project.
• Provides programmers with a picture and business rules for how the system should look and function.
• Allows someone other than the programmers and specification writers to test the system.
• Can be the basis for user documentation.
• Is the final authority for answers about how the system is supposed to look and work.
• Documents answers to the question, “Why did we do it this way?”

You will find books and articles that give you an outline of the “key” sections to be included in good computer system specifications, and maybe some of them are useful. However, if you follow the rules above – start with the process, use the client’s business terms, draw pictures, ask questions, listen to the answers, and plan enough time – you’ve got a good start on creating a document that will actually communicate clearly!

Eight Steps to Creating an Understandable and Usable Specification

• Understand the client’s business process.
• Speak the client’s language.
• Draw pictures.
• Talk to the client.
• Listen to the client.
• Invest the time to create a clear specification.
• Don’t assume a specification is complete.
• Get a return on your investment with a clear specification.

Ready to turn your vision into a clear and usable software specification? Trust Octopus Technologies for effective communication and efficient development. Consult us today!

The post Computer System Specifications 4: Creating A Solid Investment appeared first on InTune.

4. Talk to the Client.

The only way to figure out what a client wants is to actually talk to the client. Not email. Not IM. Not phone calls. All these tools are useful to clarify information originally discussed in person, but all good computer system specifications start with face to face, real-life conversations between the business person responsible for the system and the person who will write the specification. In addition to defining the business process (as described in Issue No. 22 of Info Point), the key questions to be answered when talking with the client are as follows:

• What are the client’s goals for the system?
• How will the system make a difference in the client’s business?
• If replacing an existing system:
  • Why?
  • What didn’t work in the existing system?
  • Does the information in the existing system need to be imported into the new system?
• Who will use the system?
• What information will be stored in the system?
• Will all information be entered directly into the system, or will it come in from outside the system – maybe from another system inside or outside the company?
• If information comes from another system, what does it look like? Are samples of the information for the other system available? Who is responsible for the other system?
• What information does the client need out of this system?
• What should the information coming out of the system look like?
• Does the client want printed reports or spreadsheets or will the client primarily view the information on a computer screen?
• When does the client need the system? What happens if it’s not ready on this date?
• Will the client always use the system inside the office? Should it be accessible from outside the office, too?
• Who will make the final decisions on the system design?
• Who will be testing the system, installing the system, creating documentation for the system, training users to use the system, and providing support for the system?

After answering these questions, talk to the client about each screen and function in the system, from logging in to signing off to everything in between. For each screen or function, define:

• What is the purpose of each screen or function?
• How does the user access each screen or function?
• Is a screen or function available to all users? If not, what business rules limit access?
• What information is included in each screen or function? Be specific; name each piece of information and decide what it will be – a number, text, a date, a dollar amount, etc.
• What, if any, rules apply to each piece of information?
• Is there information that can be blank? That can’t be blank?
• What is the sequence in which the information should be displayed?
• How is the information entered into each screen or function? Is it:
  • Entered directly on the screen?
  • Entered elsewhere in the system?
  • Calculated?
• Entered in another system? If so, how will it get into this system?

Can information be changed at a later time? If so, are the rules different for changing compared to adding new information?

5. Listen to the client.

It should not have to be said, but probably the most important thing that needs to be done and also is most often ignored is to LISTEN. Don’t jump in every time the client takes a minute to think; wait and be ready to listen. Don’t assume similar businesses have the same processes and functions. Don’t think a client will have the same answers as another client with a similar business. Never presume to know more about a business than the people who do the work. With this sort of attitude, listening stops. Don’t plan the next question or response to a comment while the other person is talking.

Remember all the questions that need to be answered for every screen and function in the system? The only way to get all the answers is to listen!

By the way – even with careful listening, don’t be fooled and think all the answers will be remembered, by the specification writer or the client, without taking notes. Even for small systems, and especially for large systems, take notes during the discussion. An added benefit of taking notes is that it shows the client that what he or she says is important enough to write down.

Once the first dialogue is complete, writing the specification can begin. However, all the information that is needed cannot be gathered in one client meeting. The communication must be ongoing, and the process described above needs to be repeated until all the details about the application have been successfully communicated between the client and the specification writer.

But, how long will writing the specification take, when is the specification complete, and why invest the time in good computer system specifications? These questions will be answered in the next issue of our newsletter.

Eight Steps to Creating an Understandable and Usable Specification

• Understand the client’s business process.
• Speak the client’s language.
• Draw pictures.
• Talk to the client.
• Listen to the client.
• Invest the time to create a clear specification.
• Don’t assume a specification is complete.
• Get a return on your investment with a clear specification.

Ready to turn your vision into a clear and usable software specification? Trust Octopus Technologies for effective communication and efficient development. Consult us today!

The post Computer System Specifications 3: Communication appeared first on InTune.

1. Understand the client’s business process.

When walking into a new client’s office, the first objective is to understand the unique, specific way the client’s business works. Not the way an existing or proposed computer system works – the way the business works. Although businesses in the same field may have many similarities, one size does not fit all; each business has unique characteristics and processes that ensure its competitive advantage.

As the client walks through his business processes, he steps back and thinks objectively about how the business works. Sometimes this can have an instant benefit of finding things that can be improved immediately. A good software system supports the business’s specific, unique processes; a system that limits a company to doing things just like all its competitors can be a significant liability and may cause a business to lose its competitive edge or even fail.

The overview of the business process should be the first section of all computer system specifications. The benefits of including a text – or even better, a graphical – overview of the business are:

• Gives clients a clear, specific overview of a company’s process that indicates what makes the company great!
• Gives programmers an understanding of the client’s business process that creates a high-level framework for the software to be written and helps establish the importance of the software to the business process.

For example, a client says, “I make money by selling coffee to employees. So, every day when an employee boots her computer, display a picture of a big blue cup of coffee. If it’s before 8 a.m., also show her a digital clock with the current time so she knows she has a few minutes to buy a cup of coffee before she starts work.” In this example, the business process would look something like the following:

2. Speak the client’s language.

Good computer system specifications are written in a language the client understands. If your client speaks German, it wouldn’t be productive to send her an email written in Greek. In the same way, if Bob, who owns Bob’s Manufacturing, says, “We maintain the lowest possible level of parts in our inventory,” his specification should use the word “parts” not “items.” Although certain words may seem to be synonyms, company-specific terms are not interchangeable. They’re part of the language and culture of the business. Using a business’s specific terminology means communicating in a way the client understands. Writers also need to remember the business owner does not speak “computer” language. Terms such as “object” and “class” have one meaning in the computer world but have a completely different and more common meaning in the business world outside computers. Avoid using these ambiguous words in their computer context. And completely avoid words such as “hex triplet” that would never be heard outside a software developers’ party.

3. Draw pictures.

Many ambiguities are eliminated with pictures. In the coffee example, the business owner and the person writing the specification could sketch something on a white board or a piece of paper to be sure they each understand how the screen should look. Without a picture, the business owner could be thinking the blue cup looks like this:

While the person writing the specification could be planning for the cup to look like this:

The same misunderstanding could occur with computer system screen design. Including a picture of each screen in the specification eliminates questions. For example, if the screen shown below is included in a specification, the business owner, specification writer, and programmers would know what to expect.

Once you are on the same page as the client about their business process, you need to communicate with the client by talking and listening. Both of these steps will be described in detail in the next issue of our newsletter.

Eight Steps to Creating an Understandable and Usable Specification

• Understand the client’s business process.
• Speak the client’s language.
• Draw pictures.
• Talk to the client.
• Listen to the client.
• Invest the time to create a clear specification.
• Don’t assume a specification is complete.
• Get a return on your investment with a clear specification.

Ready to turn your vision into a clear and usable software specification? Trust Octopus Technologies for effective communication and efficient development. Consult us today!

The post Computer System Specifications 2: Getting on the Same Page appeared first on InTune.

1. Understand the client’s business process.

When meeting with a new client, the first objective is to understand the unique, specific way the client’s business works – not the way an existing or proposed computer system works, but the way the business works. Although businesses in the same field may have many similarities, one size does not fit all. Each business has unique characteristics and processes that ensure its competitive advantage. Include a description of the client’s business process in the specification. Words are good, and pictures are better.

2. Speak the client’s language.

A good specification is written in a language the client understands. If a client speaks German, it wouldn’t be productive to send her an email written in Greek. In the same way, if Bob, who owns Bob’s Manufacturing, says, “We maintain the lowest possible level of parts in our inventory,” his specification should use the word “parts” not “items.” Although certain words may seem to be synonyms, company-specific terms are not interchangeable. They’re part of the language and culture of the business. When the client speaks, it’s important to listen and then use the client’s specific terms in the specification.

3. Draw pictures.

Many ambiguities are eliminated with pictures. A client wants to see information in a format that makes business sense, and a software developer creates screens that reflect the underlying computer system. Often these are completely different. Drawing the screen and including the picture in the specification means everybody starts on the same page and gets to a satisfactory result sooner.

4. Talk to the client.

The only way to figure out what a client wants is to meet with the client. Not email. Not IM. Not phone calls. All these tools are useful to clarify the information originally discussed in person, but every good specification starts with face-to-face, real-life conversations between the business person responsible for the system and the person who will write the computer system specifications. The discussion should include lots of questions from both the client and the specification writer, which leads to the next point:

5. Listen to the client.

This step should be a given. It’s probably the most important step to take, and it’s also the one most often ignored: LISTEN.

If you’re writing the specification, don’t assume that because you’ve worked with similar businesses you already know all the answers; this will trick you into not listening. Never assume you know the business better than the person who works there every day.

6. Invest the time to create clear computer system specifications.

A good specification includes a lot of information, and it takes a significant investment in time to create it. If you’re writing a specification for a computer system that includes less than six screens and functions, and one person knows all the requirements, you can probably complete the discussion about the system’s requirements in a half-day meeting (or less). As a general rule for larger systems, if the business process is clearly defined, and you’re working with a knowledgeable person (or team), an experienced specification writer may be able to cover one or two screens or functions per hour.

7. Don’t assume a specification is complete.

No matter how well you define requirements, how clear the process is, and how lovely the paper screens look, when people actually begin to use the system, they will come up with new ideas. Don’t be surprised when users also find holes in processes that everyone thought were complete and discover problems with assumptions that seemed sound on paper. Changes mean modifications to the specification.

A specification is only “final” when the code is delivered and the client says, “We’re done.”

8. Get a return on your investment with a clear specification.

A coherent specification saves time and money for both the client and the software developer. Following the above steps – understand the process, use the client’s business terms, draw pictures, ask questions, listen to the answers, and plan enough time – provides a good start on creating a document that actually communicates clearly! Each of these steps will be described in detail in subsequent issues of our newsletter.

What does a bad spec look like?

A client says, “I make money by selling coffee to employees. So, every day when an employee boots his computer, display a picture of a big blue cup of coffee. If it’s before 8 a.m., also show them a digital clock with the current time, so they know they have a few minutes to buy a cup of coffee before they start work.” Unfortunately, the specification often ends up being undecipherable as in the following example.

Nonfunctional requirements: Hex triplet 0000FF recommended for user class “coffee drinker” layer, liquid beverage object. Undetermined hex triplet indicated for numeric output subsystem, though something in the range of 808000 may be architecturally sound. Note: Using the hex triplet allows for more than 16.8 million colors. The hex triplet is a six-digit, three-byte hexadecimal number. To obtain the hex triplet value, convert the decimal RGB value, usually 0-255, by dividing number by 16, ignoring remainder, to get the first hexadecimal digit 0-F, where A-F represents 10-15 (however, if original number is 0 or 1, multiply by 255 before conversion); second digit is the remainder times 16; repeat process for each of the three RGB values.

Functional requirements: Add program to initial boot sequence to ensure application is automatically instantiated on load. Numeric digital output to be clearly readable based on standard 20-20 scale and should derive value from date/time default settings on local system; specific pixel size for “box” (square? rectangle? irregular shape?) to be determined, as is location of communications interface to be displayed in foreground of “box.” Size of container for desired end product to be determined, though recommended standards are specifically 8 ozs, 12 ozs, and 16 ozs. Note: don’t represent non-standard size for customer’s product, because if representation should drive demand, the non-standard size may be obtained only with additional unspecified lead time and at a premium cost.

This example was actually created using techno-terms from real specifications! If the goal of a specification is communication, this example specification gets an F.

Ready to turn your vision into a clear and usable software specification? Trust Octopus Technologies for effective communication and efficient development. Consult us today!

The post Computer System Specifications 1: Communication or Confusion? appeared first on InTune.