If you don't have any of these things, then what will be the system that you can complete in your proof of concept? It will be a shadow of what you desire at best. Next, there will need to be time for configuration, assistance from technical services to link to other enterprise systems, management sponsorship, time for training, and, yes, money. First, there will need to be input from management and line-personnel for any aspect of the organization that is implicated in the deployment. When an organization deploys an enterprise system, such as a timesheet or project management system, there are many things that are required to make it a success. The problem with this method is that the work you're going to be able to do to deploy this proof of concept instance is extremely unlikely to have the same support as you would get for the production deployment of an enterprise system. If it were that easy to convince management that enterprise project and timesheet software is a great fit for them, we'd deploy an awful lot more of it. In this case, the "proof" is to management, and the "concept" is the whole idea of enterprise software. Why, you ask, would someone even want to do a proof of concept then? The most common answer is that the requestor probably doesn't have the necessary buy-in from management to implement the software they're researching, and hope that if it was just running in front of them they'd fall in love with the idea and agree that it should be deployed. If you're going to conduct a proof of concept, and you have no notion of what you're trying to prove, how will you know if it's a success or failure? There's no way at all of course. This is typically met with silence and a confused expression. When prospective clients call to ask if I can help them deliver a proof of concept for enterprise project management or enterprise timesheet software, I always have the same response: "What concepts do you want to prove?" In software terms, a proof of concept should be designed to prove something. It was an inexpensive and low-risk method of proving that an electrical circuit could deliver a desired result. In proof of concept, you might spend more time at a lab bench than you would in creating the production circuit, but the only damage you could do was to the circuit board you were working on in front of you. "Bread boarding" a circuit was done to see if the circuit was possible, not to start creating it for production. This is a term that dates back many years and is popular in electrical engineering. The term "pilot," in the software world, is often blended together with other challenging evaluation methods, like "proof of concept." Let's take a look at what these terms mean and how you can best use them in your own enterprise evaluation process. When someone on an aircraft says "pilot," we're all very clear about what is meant, but when someone who is evaluating software options says "pilot," I'm not so sure. These kinds of calls always make me take pause. A prospective client of ours called recently and asked if they could "pilot" our enterprise project timesheet software. It's a great story but my going back to re-read it recently was triggered by something very different. The plane, passengers, and crew all landed safely. Mark Gongol, a B1 bomber pilot in the US Air Force, stepped into the breach. After the pilot of a flight out of Des Moines, Iowa suffered a medical emergency, the co-pilot made a request for any pilots on board. I re-read a remarkable news story from a true incident just like this that happened back in December 2013. "If there is a pilot on board, would he or she please ring their call button?" is something no passenger ever wants to hear.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |