"Ensuring Successful Custom Software Projects"
Ensuring Successful Custom Software Projects Tim Strandberg - Avatech Solutions, Inc. CM201-2 Recent statistics show that over 60 percent of all software projects fail due to poor planning, insufficient resources, a lack of executive support, changing requirements, or all of the above. This class is intended for anyone who has struggled to implement a custom CAD solution or who is planning to implement a custom software solution within their company. Gathering requirements, assessing needs, managing development, planning integration, and calculating return on investment are among the topics discussed. Participate in this interactive class to learn how to identify and avoid project pitfalls. Special emphasis will be placed on methods proven to make custom software projects a success. About the Speaker: Tim is a Senior Project Manager for Avatech Solutions Software Development group. He has 7 years of experience helping clients define and implement their custom software applications to extend the functionality of Autodesk products. Tim is responsible for developing software specifications, guiding the design of the proposed software, minimizing development risk, and overseeing the successful implementation and training of custom software solutions. email@example.com Ensuring Successful Custom Software Projects Hi, my name is Tim Strandberg, and I’ve been guiding companies through successful custom software projects for the last 7 years. Companies of all sizes, from multi-national Fortune 100 giants to the 2 man design shop around the corner. And, even though business practices may vary greatly, one thing they have in common is the need and desire be successful in designing, developing and implementing custom software. They may be considering something as simple as a batch plotting routine that saves 10 minutes a day or an application that collects sales requests, configures product lines and ties into their back office ERP system. At both ends of the spectrum it is crucial to follow the same basic steps. In this session I will describe those steps so that you too may ensure your companies success in such a project. The Big Picture As with any endeavor it is important to know what you’re trying to accomplish before jumping in head first. It is best to start with the 30,000 ft view. • What is the driving force causing us to consider a custom software project? o o o Is there no software that provides what we need out-of-the-box? Do we require more control of the output? Our stakeholder has budget money to burn? Who’s idea was this anyway? This might sound silly, but what is the real motivation behind this project? Are you trying to reduce pre-sales Engineering? Are you trying to reduce tedium and errors in the drafting department? Try to identify or classify these goals as they relate to the company as a whole and not list them as benefits for a lone department or person. Remember, we are still at the 30,000 level. It’s much easier to justify a five or six figure budget to provide real-time access to the most current drawing specification for the national sales department than to try to get a PO for a system so Larry and Joe don’t have to waste time looking for drawings. It’s all about the spin. Find out what is important to your stakeholder. Is their vision father reaching than yours? I have seen this time and time again, the CAD manager would like some automation to help with document management while his boss’ boss has a vision for an MRP driven electronic document imaging system. Talk to the big guys, the folks wearing the suits, the ones signing the PO, share their vision. If you are the big guy, share your vision with the people you trust to get things done. Put your dream on paper. Sketch it out. Let it come alive. You will be amazed at how others will see the value in your idea as well as help you find additional benefits and ways to pay for it. Page | 3 Ensuring Successful Custom Software Projects Gather Requirements In order to make your project a success you have to know what the requirements are that make it a success. Let’s take a closer look at what gathering requirements means. • What problem will this solution solve? o Just what exactly is the problem? What motivates us to consider this solution in the first place? Identify the three or four driving factors that make up your pain points. Are we trying to become more efficient or cost effective in a particular area? What are the roadblocks preventing that efficiency? “It takes too long to find existing drawings.” “The shop doesn’t always have the latest drawings.” “Presales engineering costs are killing us”. Get as specific as possible as these are the items you will use to drive the project as a whole as well as justify your development budget. Many times an outside vendor or business analyst can make a better assessment than your people because they tend to take nothing for granted and have perspective on what a large number of other firms are doing). o • What are the use cases? o How will the application be used to solve the problem(s)? Come up with as many use cases as is practical. Identifying early on the step-by-step workflow will determine if the proposed solution helps solve the problem or merely disguises it with complexity. Use case definitions are also a great place to quantify your problem domain. Is this process really so bad that it justifies developing a custom solution or is it simply something that we have to live with. You would be surprised at how often a $10,000 solution is proposed to solve a $1,000 problem. But that doesn’t mean you should ignore the $1,000 problems either. Think of use cases as another method of process documentation; something your organization can benefit from anyway. o o • Who will use it? o Identify the proposed users of the new solution. Do these users exist today? Will we need to hire additional staff to use the new application? What training will new or existing users require? Page | 4 Ensuring Successful Custom Software Projects If the intended users are part of the existing team will they embrace the new technology or view it as a burden, something they have to deal with, but not by choice. It will be your job to help ‘sell’ the users on the use of this new application. A batch plotting application will reduce their workload allowing them to work on more value-add type operations. Don’t let the rumor mill get started. Keep them informed, and more importantly ask their opinions. Some of the best subject matter experts, (SME’s), you have are those workers who deal with the problem on a daily basis. o • What is the primary vision statement? o A project vision statement allows a project team member to explain the project to someone in two minutes or less. A sample vision statement may be something like: “The XYZovator will provide real-time Engineering document management support including an electronic shop drawing viewer, production run job ticket printing and sales quote generation. The XYZovator will streamline our Engineering, Production and Sales departments by allowing quick, easy access to the most current product information.” o Vision statements don’t need to be glamorous or elegant nor do they need to be authored by someone with a Master’s Degree in marketing. Simply state the vision in concise straight forward terms that everyone can understand. All vision statements should contain the following: Who is it for? A brief description of what it does. The key benefits of using such a product or system. o o • What are the initial design goals? o Once the basics are captured in through the gathering of requirements, it is time to start thinking of how we might solve this problem or achieve this goal. What types of technologies are available that would serve our purpose? What is close to what we need that we can modify? Does a competitor have something similar? How can we improve on that? Page | 5 Ensuring Successful Custom Software Projects This process is somewhat iterative and a great place to implement brain-storming with your SME’s. Since the SME’s are likely to understand the problem at its core, they also have a likely work-around or solution in mind. “We need an application that would let me <fill in the blank>.” At the same time, SME’s can occasionally have too tight a focus on the problem. You should also encourage team members to step back and take a broader view – is the problem we’re discussing a symptom of a broader “disease”? Should we attempt to treat the larger disease rather than this symptom? So, we need a solution that does “X”. Does this need to be a stand-alone application? What platform should it run on? What key features that the users requested do we need to include into the interface and workflow? Don’t get bogged down here. Remember, we’re still at a 20,000 foot view of the overall project. o o o • What is the preliminary solution? o Now that we have the goals defined, have collected some user feedback and have a good sense of what we’re up against let’s start talking through how to solve our issue. By mapping out where we are and where we need to be we can start plugging the gaps with bits of known technology and software to satisfy our goals. We know we need online viewing, so let’s define what we are going to view. Our Engineers use AutoCAD so we need to define whether we’re going to view DWG or DWF. Wait, we only want the shop and Sales to see the latest, greatest rev of our drawings, so we better only expose what’s been released for manufacture. Time to plug in our document management piece. Does Productstream have the API to support such a task? It does? Great, moving forward… We also stated we want to incorporate job tickets along with our drawings. That means we are going to have to tie into the back-office system. We find out that they can give us SQL data for each days run. You can see a framework of the various components for this application starting to come together. We don’t know the exact details yet or even exactly what it’s going to look like. But, we do know the technologies we are going to use and can deduce the skillsets our development team will need to pull this off. o o o o o Page | 6 Ensuring Successful Custom Software Projects Critical Success Factors • Scope o One of the major factors to success is to determine exactly what our application will do or what problem it will solve. It is just as important to determine what it won’t do. Stating our project scope will let everyone know up front what the application is capable of. Many projects have died a long agonizing death due to the project manager’s old enemy, “Scope Creep”. Too many times over my career I have heard, “Well, it should do this…” Maybe it should, and maybe it will in a future release, but in this version the spec says it will only do it this way. By setting the Scope we have a milestone to reach when we can finally call it done. Milestones also provide a measure of project progress. It is hard to show progress when we are still weeks or months away from delivering a final product. By defining intermediate milestones that are achievable on a reasonable basis we can measure whether the project is on schedule. The viewer component is complete. The SQL data reader is working. The UI is ready for review. I think you get the picture. o o Planning • Functional Design Spec o The functional design spec, (FDS), is a derivative of the Requirements gathering process and is sometimes lumped into the same activity. The FDS identifies the problem, states the goals, major functional requirements, and proposed solution to the problem. The FDS may also include general budget estimates for application development, often referred to a Rough Order of Magnitude, (ROM). For most projects the FDS should not go into great detail. Think of it now as a 10,000 foot view. A comprehensive forward thinking development team could probably come up with the desired solution based only on the FDS but they would have to use considerable imagination. Sometimes that’s OK. If it’s a small project maybe all you need is an FDS. An FDS should capture all the important elements as well as re-state the scope and vision. Above all we need continuity between the Requirements Gathering, Vision, Functional Spec and Detailed Technical Spec. Remember, you may have different people working on various aspects of the project and they may not have participated in all conversations. Page | 7 o o Ensuring Successful Custom Software Projects • Detailed Technical Spec o The Detailed Technical Spec, (DTS), finally gets to the granular level. Just as its name implies, it all about the detail. Logical Design The logical design describes and defines the business logic behind the operations of the software. Business logic is typically compiled by interviewing the people in the organization that deal with those topics. If you are writing a quote generator that build simple drawings on the fly, you must know the engineering and manufacturing constraints that govern what you can build. Also, your quote generator will require a pricing matrix. Based on what you are designing what are the material and manufacturing costs? What is our desired margin? How often does that change? These are just a few examples of business logic. We can also have mathematical or design logic to contend with, e.g. If we are building a 16” widget then the bracing has to be 1/4” material, if we move to the 14” model then 10ga. material will suffice. o Physical Design Physical design control how your application will look and feel. Build wireframes and mockups of the User Interface. You know what’s it’s supposed to do from the requirements and functional spec. Show your team exactly what it will look like. Describe the workflow in detail. How many button clicks will this operation take? Will the application automatically save the file in all the required formats or will that be the user’s responsibility. Take nothing for granted. You know what they say about making assumptions. In this game it means you end up writing it later when you have no budget or time left. For very large projects a physical prototype or proof-of-concept application may be warranted. This application may not include all the bells and whistles but will give you the general idea of whether your design will be usable and a generally accepted solution. o Risk Management Page | 8 o Ensuring Successful Custom Software Projects Risks are inherent in any project. How we manage that risk largely governs the success of the project. It should go without saying that proactive risk management is more desirable than having to react to a risk that was unforeseen. The risks are generally known to project members but poorly communicated. Risk can take many forms. • • • • • • Poor planning Under-budgeting Scheduling Changes in Technology Organizational pressure Organizational politics An effective project team assesses risks continuously and uses the information for decision-making in all phases of the project. On many projects, risks are assessed only once during initial project planning, Major risks are identified and mitigated, but then are never explicitly reviewed again. This is not an example of good risk management. Reactive risk management is limited to dealing with problems as they occur. Never a good position to be in. Proactive risk management is recognizing the risks and heading them off or mitigating them before they become problems. Risk assessment is an ongoing task and applicable risks should be considered in all decisions. All risks should be defined with regard to their source, problem consequence and project consequence, such as: “We will forego formal user training and as a result our users will require a longer ramp-up time.” A risk must be clearly stated before it can be addressed. Development • Development Team Page | 9 Ensuring Successful Custom Software Projects The development team is a crucial component to your project’s success. Do you have resources in-house that have the necessary skillsets and experience? If not, hire them. Whether you hire a vendor or a temporary contract development team it will be money well spent. I can’t stress enough the importance of choosing skilled, highly trained, trustworthy people. Assuming that your present staff will eventually figure it out is like assuming the bricklayer building your new office will eventually figure out how to solder the water pipes. They’re both construction workers, how hard can it be? Just because you’ve got someone who used to code AutoLISP for AutoCAD doesn’t mean they have a grasp on what is involved in writing an nTiered C# application to tie your order entry system to an automated DWF publisher. We’ll make the assumption you are using a competent team of programmers, but they still need direction and must be held accountable. Bless their hearts, if left to their own devices software developers can be you’re their own worst enemy when it comes to scope creep. Don’t get me wrong; they take a huge amount of pride in their work and therein lies the problems. When writing a particularly clever bit of code it’s easy to think, “Well, that’s really neat, but if I did this too it would be super cool!” A resent study indicated that commercial code contains from one to seven bugs per thousand lines of code. I think you can see that ‘Super Cool’ was not in the spec. The easiest way to ward off problems in general is to make sure that communication with the development team is frequent, constructive and truthful. Many times, especially when dealing with a vendor you will be dealing with that team’s project manager. This is out of necessity. As a project manager myself, I can state that if I let clients call a developer every time a question arose my people would never get any code written. Developers do their best work in an environment where they can concentrate. Having a point-of-contact insulates them from too many distractions and keeps them from “harmless change requests” by handling them through an official mechanism. The simplest method to initiate communication is to conduct regularly scheduled meetings. These meetings can consist of face-to-face set down meetings. But will more likely consist of conference calls and WebEx presentations. Such meetings allow everyone to state the current project progress, next milestone delivery dates, issues with the current build, etc. o o o o • The Code o Each organization takes a different approach to creating, controlling and safeguarding the code. Page | 10 Ensuring Successful Custom Software Projects Depending whether you are using internal resources or outside vendors may determine exactly how this process works, but it should contain some common elements. Source code must follow a standard. Just as engineering drawings can benefit from a drafting standard, code can benefit from a coding standard. This makes maintenance and expansion of the code at a later date much easier. Source code should live in a common repository. Regardless of whether you are employing a single developer or a team, it is important to preserve the integrity of the code. This is most easily handled by utilization of widely available source code vaults. Microsoft Visual SourceSafe, SourceGear and CVS are but a few that provide varying degrees of functionality. All provide check-in/check-out features that ensure that the team is always working on the latest build. In addition, some of these softwares provide features to help with code merges, diff checking, and more advanced concepts such as branching. There are additional tools that allow for automatic nightly builds, automatic backup, etc. that help streamline the process. o o o o • The Intellectual Property o If you are engaged with a software development vendor, the topic of who owns the code will come up sooner rather than later. Most vendors are willing to negotiate a viable agreement regarding who retains the IP. Some are straightforward and state that the client, (you), own it lock, stock and barrel and they are just the hired guns. Others will provide libraries that do some of the work and carry a separate license agreement. Rarely are vendors interested in owning your code outright. Personally, I would rather the client take most or all of the ownership. Even though we’ve written batch processors dozens of times you might be surprised how different each one is. o o • Documentation o Documentation should take multiple forms. First and foremost the code should be liberally commented following the agreed upon coding standard. Next, the application itself should provide user documentation. This typically takes the form of some type of interactive, searchable Help menu system. Finally, documentation of the entire system, from business case to technology disclaimers to installation and maintenance instructions should be created. Page | 11 Ensuring Successful Custom Software Projects There is nothing more aggravating than trying to resurrect someone else’s code when nobody remembers exactly how it’s supposed to work or how it’s supposed to operate. In short, take every step necessary to protect your investment. Did you know that over 50% of a software projects life-cycle cost can be attributed to maintenance? o o Testing • When your application starts coming together we need to be diligent in testing to see that it works properly. Remember the use cases I stated above? Now is the time to use them. There are some simple methodologies to consider when testing. o Test often. It’s amazing how many things get broken from adding a new procedure or function. Regression testing becomes second nature when you test on a regular basis. Regression testing applies to new development as well as future changes. For every feature you add, go back and test from the beginning. Test thoroughly. Make sure you test the whole application from start to finish. There will be times when not all features are complete enough to test but take it as far as possible. This will also help alleviate regression issues. Test naked. Whoa, I’m talking about testing in a pure environment, not your office dress code. Test on a machine that’s dedicated to testing. That machine can be a virtual machine, but should as closely replicate the user environment as possible. There is nothing more disappointing than hearing a developer say, “Well, it works on my machine…” Make sure your technical spec addresses acceptance testing. If dealing with a vendor this is usually spelled out in the general Terms and Conditions. Developers, Project Managers, as we as the project Stakeholders have be in agreement as to when the project has acceptably met the project requirements. o o o Logistics • OK, we’ve got a functioning application that’s relatively bug free. What do we do with it now? o Our FDS and/or DTS should have named any special requirements for hardware, supporting software or networks. Hopefully, while our development team has Page | 12 Ensuring Successful Custom Software Projects been busy coding, the IT department has been purchasing any required workstations and servers. o Our DTS should have also included how we intend to distribute this application. Are there special requirements regarding the installer rights? Do we need special licensing agreements for our sister company in Germany? Does our application require special security if it deals with sensitive material? o Training • We must assume that even though every effort may have been made to this application as simple to use as possible our user’s might not inherently know how to use it. As we are developing use cases we can also be developing an outline for training. Training can be tightly structured or very casual. In either case, documentation should be created that instructs a new user exactly how to use, troubleshoot and maintain the application. Team leaders get re-assigned, people come and go, things change. Protect your investment by properly documenting the training methodologies and the project as a whole. Support • Lastly, who is going to support the application? If it’s an in-house resource be sure to choose someone who understands the technologies involved. It’s not unheard of to include that person on the project team from the start. If you used a vendor or other outside resource for development it may be in everyone’s interest to have that vendor provide support and training as well as maintenance. Most vendors will agree to perform such duties as part of an annual maintenance or support agreement. • Parting Thoughts The single thing that leads to successful custom software projects is communication. Communicate openly and honestly with your project team. If you have ideas, express them. If you have concerns, voice them. If your development team makes you a hero, reward them. If you take this approach in your custom software projects when things go less than perfect your team will be there to help you turn things around. Good Luck on your next project! Page | 13