Consider this scenario (you may want to sit down before reading further.):

You’re the CFO of a small to midsize, but fast-growing company. Your boss, the CEO, has come to you with this mission:

• scope out an important, upcoming outsourced custom software project for your company.

Let’s say it’s in the Internet of Things (IoT) space.

He respects you as a smart, capable leader but knows this project is not exactly in your wheelhouse. Nevertheless, he has confidence you’re the man for the job and will dive in and produce great results. Assuming you don’t panic and make a frenzied call to your recruiter, how do you go about accomplishing this important mission?  

Although you’re plowing new fields with this project, take a measured, well-defined and well-outlined approach to the project, and you’ll end up surprising yourself (and your CEO) with the quality document you can produce.  

Consider the following methodology and detailed action plan. It will prepare you to walk into the CEO’s corner office with a plan that will impress and allow your company to embark on a successful scope definition for a critical corporate project.

First Things First

The most important consideration, at the beginning, is to fully understand your project goals. You may not speak the developer’s lingo, but you must be able to understand and communicate your project goals so potential developers know what you want and what your target is.

As an example, a vague description goal such as “this software should allow us to measure temperature changes in field machines” won’t do. Software (and developers) require exactitude. And it’s up to you, the client, to provide it.

A better requirement statement in this instance would be, “this software should relay machine temperatures every 15 minutes or when a 5C degree rise occurs in lesser time intervals.”

Information relay must occur in all types of weather, regardless of temperature or time of day. Any sudden temperature rises, as defined, will be relayed, via text, within 60 seconds to appointed company personnel.”

Define your desired outcome in as many specifics as possible: how will your processes change, what will be different, better and more efficient with the new software?

Even though you may not understand the technologies involved or the tools or methods your developer will use, your responsibility is to paint the picture you want when the job is done.

We’ll talk later about what and how you explicitly convey those items.

Do You Enlist an Outside Consultant?

Some companies like yours, understaffed or with inadequate understanding of how to scope a project and vet software developers, will bring in a consultant, someone to help them enunciate their needs and put together an RFP document they can present to potential developers.

That’s not a bad approach. Hire a good company or individual, and they will cut corners and lend expertise that you lack. Save time, buy skills and coaching, and you have a solid document and methodology to assess possible developers.

But these consultants aren’t cheap. So, let’s say that’s a lifeboat you don’t have. No worries, we’ll hit the highlights below that your expensive consultant would have.

Measurements and Milestones

Let’s look at the major calibration points you must think about as you scope the project and prepare to choose a developer.

Two keystone markers are budget and timeline. But, you say, you don’t really know how long or how much such a project should cost. Fair enough.

You may need to solicit general information in these areas from associates, known or yet to be known, who have undertaken such projects. Trade associations, forums, and many other sources online and offline can guide you here.

As for cost, you will have a number beyond which you cannot go, and you will have established expected ROI on such an investment, so you have some markers. And, like most major projects, whether software development or other capital expenditures, negotiation on deliverables, options, and other key components will be part of the final purchase order.

As for other major requirements, they are often broken down as functional and non-functional. This is a good approach to be sure you cover all areas. Let’s consider the items which would be a part of each classification.

Functional Requirements

Think of functional requirements as relating to the system’s operation. It includes:

1. Business Rules:
   • Does the system achieve the business objectives you outline?
2. Administrative Functions:
   • Does the product adhere to established and acceptable operations?
3. Authentication:
   • How does the system secure identification and user rights and report and track them?
4. Audit Tracking:
   • What systems are established to record actions throughout the system?
5. External Interfaces: 
   • What facilities and regulations does the system impose for external communications?
6. Certification Requirements:
   • Does the system meet internal, industry, or governmental requirements?

Reporting Requirements: Does the system adhere and meet your reporting requirements?

Non-Functional Requirements

Non-functional requirements spell out HOW the system performs a specific function. Think back to our machine temperature requirements above.

It detailed frequency, response time, and specific actions. That’s a non-functional requirement. Typical such requirements you must consider include:

1. Performance measurements:
   1. Things like response time and throughput.
2. Scalability:
   1. What ability and facility does the system have to expand?
3. Availability:
   1. You must establish expected uptime, e.g., 98% guaranteed uptime.
4. Reliability:
   1. This is a measurement of the system’s probability to consistently operate according to predefined specifications.
5. Recoverability:
   1. What is the system’s ability and facility to resume operations after a fault?
6. Maintainability:
   1. To what degree can the software system be understood, repaired, or improved?
7. Serviceability:
   1. How easily can the system be diagnosed, analysed, and returned to operation after failure?
8. Security:
   1. How and to what degree of certainty is the software system protected against malicious attack, whether from hackers, malware, or other such risks?
9. Regulatory:
   1. Does the product adhere to guidelines, regulations, or protocols peculiar to your business.
10. Manageability:
    1. With what ease and efficiency can the system be maintained, monitored, and regulated to ensure smooth operation?
11. Data Integrity:
    1. Is data internal to and transmitted from and to the system accurate, consistent, and reliable?
12. Usability:
    1. To what degree is the software usable by endusers to achieve objectives for which it was developed?
13. Interoperability:
    1. Can the system effectively and efficiently communicate, exchange, and use data with other systems for which it was designed?

Walk into your CEO’s office with a document of this calibre: thorough, thoughtful, and detailed, and you may just have inherited the mantle for future projects.