by Seth Temko

Whenever you follow classic software or product development process then you have two primary roles needing to be filled by strong, smart people.  Most people have heard of the project manager.  That person is responsible for coordinating resources (people) and processes to deliver products on time and on budget.  But the biggest measure of project success hands down is if the new product adds value to its business.  There is a set of metrics used to judge business success and they are business requirements.  You can read the article on that topic here.  You need a business owner tick, and the project manager tock - for your project clock to tick along.

A business manager, non-technical, needs to be part of a group of business people who creates the lists of business needs that must be satisfied in order to claim the project is successful.  This ultimately is the criteria that determines the functional success of the project.  One person, a business manager, needs to be the "business owner" for the project.  So there is no confusion, it doesn't have to be the actual owner of a business.

The business owner of the project needs to be the person the project manager is beholden to.  The business owner needs to have regular meetings with the project manager and make sure the project is meeting time and cost schedules.  The business owner also has the responsibility of clearing business barriers inside the company.  Barriers can be unpaid bills, uncooperative business managers, poorly defined business processes and just about any non-technical thing you can think of.  Ultimately, the business owner will judge the project deliverables and declare whether or not the

You MUST have a business owner involved in the projects.  It's absolutely necessary for success.

by Seth Temko

Cloud is "the" buzzword for technology since 2010.  Cloud this and cloud that.  I especially like "we're in the cloud".  "Cloud" as a buzzword is very poorly defined so it can have a couple of definitions.

Cloud as software services.  Cloud as software services used to go under the buzzwords, ASP - application service provider and SAS - software as a service.  If you've used turbotax or quickbooks online then you've used "the cloud" as software.  Basically your using a browser as the GUI, visual interface, and all the logic and database functions are happening on servers somewhere.  For most business users this is what cloud means.  It means you'll use a computer and browser or a smartphone and with the Internet connection on those devices you'll access movies, music and data running on a company's servers.  At this point you're probably thinking, okay, nothing new here.

For businesses the advantage of cloud as software services is it can take the software on a desktop model of doing business and make it centralized and cheap to offer those same software benefits to infinitely more users at rediculously small per user costs.  If you own your own software, this kind of business model can tremendously benefit your business both in reducing support costs and in expanding your client base.

This blog that you're reading right now is provided by Weebly (www.weebly.com) which is web based software for creating and maintaining websites and it's hosted by their servers.  If you want a basic site, I highly recommend them.  The service starts as free and for a small price you get more functions (a common online business model for these kinds of services).  There are many other companies that provide similar and good services.  You can always search weebly review or weebly competitor on Google search to find others.

Cloud as a platform and computer power.  Service companies create whole warehouses full of servers that have huge data pipes.  All the functions for logic and data storage are available in that huge array of computers.  Companies pay for computing power that is immediately scalable to handle huge data and customer loads.  So instead of pointing at a couple of servers and saying that is my computer farm you can sweep your arms over the whole darn building and say that is my available computing power.  Essentially it's computing power used as a utility, like your electric meter.  You turn on your AC and the dial spins faster and you're billed more for the power use.  Lots of customers hit your website and the computer "power meter" spins faster and you're billed more for the computing use.  NOTE: Even with cloud platform providers there can be a lot of variation in what you need to do with your software/web applications in order to "live" on the platforms and take advantage of the computing power.  Some allow you to build your software on a common software development platform like Microsoft technology and you're good.  Others, like Amazon, require you to write software to their specifications.  You really need your technical people to get involved in these kinds of pros and cons decisions.

For businesses the advantage of cloud as a platform is primarily you get a world class server farm that is able to handle tremendous user loads for a fraction of the price of having and maintaining in-house servers.

by Seth Temko

I don't know why but when it comes to business systems and custom software development projects most non-technical people just want to punt the ball over to the technology people.  I assume most times its largely becuase they feel they can't contribute without a technology background.  THAT IS A HUGE MISTAKE. I can't stress this enough so... THAT IS A HUGE MISTAKE. Business Requirements are your business needs in a documented form that the technology group is to build to. If you trust your tech people exclusively to understand the ins and outs of your business and hence your business needs then you are setting yourself up for disappointing results, extended delivery schedules and cost run ups for your technology projects. It doesn't matter if you are seeking technology that is custom coded, prepackaged software or software as a service via the web, each company needs to have business managers write business requirements. It becomes the litmus test for creating value to your business by its technology. If the technology doesn't meet the business needs then managers shouldn't accept the technology delivery. That go, no go decision needs to be made against a Business Requirements document. That document is created with business managers and handed off to technology managers for review and clarification. Before it is fully accepted it is signed off by both groups and it is the "guiding light" for technology documentation, technology development and final technology delivery.

If business managers short cut that process or remain uninvolved then expect to be disappointed and worse yet risk that you spend money and time and add little value to your business.

What Goes Into a Business Requirements Document:

• Business background - it is very possible that outside technologists will be involved in your project and have no knowledge of your business or industry.  Let's face it, they see the world very differently from the way you do, so help them. Supply them with details on what your business is about. This includes who the customers are, what you provide as service, most critical competitive advantages and a little about what your business is not but outsiders would consider. Put in what your core competencies are and what is outsourced.
• Prompting for Project - put down the business reasons for why you are pursuing the project. You can touch on technology reasons (i.e. current systems not scalable, too expensive, etc.) but you should stick to business reasons (i.e. scalability - your business is growing or diversifying overseas).  Make sure to list the current systems and support architecture that exist in the business and whether they are relevant to the project or not. Even if you think they are irrelevant still list them.
• What business value do you need - list all the business improvements that you expect from the project (i.e. less than 1 day to train someone, instant report generation with real-time data, etc.). Put as many as you like - sky's the limit at this stage. BUT, prioritize them. Most companies don't have the budgets to get everything they dream of.
• Cost savings and payback - make sure to list any cost savings and payback objectives to the project.
  Limits on licensing and costs - make sure to explicitly state what is allowable and not from a one-time and on-going budgeting basis. If you want a freeware system or its your preference then be explicit about what you're looking for.
• Set Your Technology Preferences - culturally some companies just want to stick to Microsoft or Oracle or custom code. Make sure to describe your preferences.
• Determine your business representatives - you should determine up front who on the business side will be interfacing with the technology folks during the project. These will be the "go to" people for process questions and minor item decision points.
• List anything existing you like - make sure to provide links to web sites and technologies for anything you like and think you may want to have. This could be small things like look and feel of a software interface to major function items like user defined data interfaces. The more specific and solid the examples you can provide the more likely you'll get a final result you're happy with.