How To Avoid Failure With Your ASP.NET Software Project?

Development ADDRESSING THE IT NEEDS OF COMPANIES focus How To Avoid Failure With Your ASP.NET Software Project In today's world, whether you're starting a new business, upgrading your business processes or revamping your business as a whole, web technology has to become one of the leading factors to be considered. To stay ahead of your competition you have to constantly innovate and find new ways to add more value for your clients. From product development, to sales, to delivery and to support, a coherent, integrated software solution enables your business to not only start successfully, but to expand that success as your business grows. That all starts by developing a software project plan that will give you not only what you need now but also that necessary future expandability. If you want to ensure success in your ASP.Net software development effort then you need to follow these 10 steps to project planning. 1. State the Goals As in any endeavor in life, whether building an enterprise software solution or building a house, the first step is always determining the requirements and clearly stating the goals of the project. Sometimes people jump too quickly into the details without first pinpointing the real issues in an organization. Describe your vision of the project by answering the question “What is the real problem we are trying to solve here?” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

Think about current and future technology: Computers are faster, servers more powerful, storage less expensive and more flexible and access is more portable than ever before. Between Moore's Law and the continuing pressures of business needs, new ways to leverage technology will continue this trend. Today, smartphones, tablets, and wireless connectivity are redefining how data is accessed. Here are some questions to ask yourself to assist in identifying how new technology can help you reach your goals:  What is new and trending that can benefit you?  What pieces of today's technology world can you use now such as mobile devices?  Who will use these devices and how will these technologies integrate into your organization? With a great intranet, anyone in-house can get to what they need easily but if your business revolves around salespeople working around the country or overseas, then internet accessibility to data is going to be an absolute necessity. It’s important to identify major architectural decisions like this up front. Your stated goals will become the foundation upon which you will build the rest of your project plan. They will give you clarity and purpose to ensure project success. One way to achieve this is through S.M.A.R.T. Goal Setting. SMART refers to goals that are Specific, Measurable, Achievable, Realistic / Relevant and Time Framed. Specific You need to be very specific in your goal. It’s not good enough to just say “We want a faster system.” Instead, specify that in real terms, for example “We want to be able to handle 500 concurrent users.” Or “We want to sign up 2500 new clients.” Measurable Goals need to be measurable. The project goals need to be reviewed periodically during the project planning process to make sure that proposed solutions align with goals and scope creep hasn’t stepped in. Likewise progress towards goals must be measured during implementation and a post-delivery analysis of the project goals will tell you if you achieved success or not. Achievable It must be physically possible to achieve the goal. Realistic Just because a goal is possible doesn’t necessarily make it realistic especially when viewed in the context of staffing, budget, technology and time constraints. “S.M.A.R.T goals are: Specific Measurable Achievable Realistic / Relevant Time Framed” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

Relevant The goal needs to be relevant. You’ve probably heard of the 80-20 rule: As a rule of thumb 80% of outcomes can be attributed to 20% of the causes. Focus on the 20% of things that will make the most relevant differences in your organization given the resource constraints you have. Time Framed Setting goals to a time frame gives the goals structure. Open ended goals rarely succeed. Now armed with clarity and purpose and a full understanding of your end target, you are ready to start filling in the details of how you are going to achieve the goal. 2. Identify the Actors/Roles Who will need access to what data and how do they need to access it? Each actor plays a different role in the company, has a different view of the data and different levels of access. For example, access granted to the executive will likely be different than that granted to a salesperson. Some examples of actors are:  Salesperson  Accountant  Executive  Department Manager  Machine Operator Individuals (actors) in an organization often fill multiple roles, especially in a small company. So it’s important that you make a distinction between the role and the role-player. The terms actor and role are not interchangeable. Just like in the movies the actor Jack Nicholson plays the role of bad guy in one movie (Batman) and then the role of good guy in another (The Bucket List). So don’t fall into the trap of trying to define a system for a specific individual but instead for each role that the individual plays. 3. Identify Processes / Data Flow Next identify the business processes and how data flows through the organization. Another term for this is “Use Case”. Use Case (n) - “a list of steps defining interactions between an actor and the system.” Each actor will have a different set of tasks that they need to perform to do their job. Identify each of these tasks for each of the actor’s roles. This information “Actors are people who make decisions and take action on the data in the system.” Use Case (n) - “a list of steps defining interactions between an actor and the system.” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

will be critical for the next step (defining the data). For example, a salesman may be entering sales data, running sales reports, and accessing client data whereas the executive may just be interested in high level reporting. Each task may have several steps from beginning to end and may require several complicated screens. All of these steps must be documented. Some of these steps may be identical to current manual processes in the organization but others will require process reengineering in the context of the new capabilities made possible by the new software system and new technology such as mobile devices. You may have more processes in your organization than you realize. It’s often very helpful to map these process flows pictorially. This is especially helpful in conveying your design concepts to the reader of your design document. A good tool for this is Microsoft Visio. “Process Flow Diagrams allow people to visualize all of the steps in a complex process.” An example process flow diagram produced with Visio Be sure to think through of all of the possible scenarios for each given task an actor performs. In very complex scenarios with lots of exceptions and decision points it’s helpful to further define a process with a flow chart to graphically depict the business logic of the process. This makes it significantly easier for the reader of the document to grasp complex logic. Microsoft Visio can be used for this type of a drawing too. Typically flow charting the logic of an application is a very tedious task so it is usually reserved for only the most complex and critical portions of an application. Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

“Flow Charts are tedious to produce and are usually reserved for only the most complex and critical portions of an application.” An example flow chart produced with Visio 4. Define the Data Next, define the core database requirements identifying all data to be captured. When planning any software project, the database will be the core of your business information flow and getting it right the first time is critical to the success of the project. IT business processes all revolve around data: storing it, manipulating it and making use of the results in all aspects of your business. This means customer data, product data and shipping data all have to co-exist in a platform that enables everyone in your business to access the data they need, quickly, securely and easily. Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

The use cases defined earlier will dictate what data needs to be captured and manipulated. First, the major tables need to be identified. Each table will hold like-type records. Table examples would be things like:  Customer  Company  SalesPerson  PurchaseOrder  PurchaseOrderDetail (a line item on a purchase order) Second, each record will have a number of “fields”. For example, fields in a Company table may include:  CompanyID  CompanyName  Address  City  State  Zip  PhoneNumber Third, relationships between the tables must be defined. For example, a PurchaseOrder record will have several child PurchaseOrderDetail records each representing a line item on a purchase order. This is called a parent/child relationship or a one-to-many relationship. All of these relationships must be identified and architected in such a way as to allow for proper reporting and expandability of the system in the future. A poorly designed database will lead to a whole host of problems down the line. There are a number of tools on the market for designing a database and producing a nice database diagram during the planning stage. But one of the best tools we have found is to use the database server itself. We find it is just as easy to create the actual database in SQL Server during the project definition stage. And there are a number of advantages in doing it at this time:  You can define every table and every field  You can specify the keys of each table  You can specify the relationships, such as parent-child, between the tables  You can enter some dummy data and actually test complex queries to be sure you can produce the types of reports that you want  You can have SQL Server produce a diagram that you can place in your design document  and best of all, when you start moving out of the planning phase and into the coding phase, the database will already be built and ready for the programmers to start using! “The database will be the core of your business information flow and getting it right the first time is critical to the success of your project.” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

“FACT: A common reason for software project failure or cost overrun is because not all of the screens were identified and designed during the planning stage.” An Example Database Diagram produced by SQL Server 5. Mockup the Screens Next you will need to translate the needs and tasks of each actor into a series of screen mockups that allow them to perform each task that their job dictates. The screens also define the flow of each activity. To properly plan a software project *all* screens in the system must be identified. Not Identifying all of the screens leads to grossly underestimating the amount of work needed to complete the system. Often people mockup the public facing portion of a system but neglect to design the back end. Depending on the situation the backend may even have twice as many screens as the front end. The screen mockups have the extra added benefit of involving the system stakeholders and future system users early on in the process. Often users Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

cannot visualize how the system will work. Remember, they are experts at what they do for a living but not experts at software design. They’ll have a hard time digesting a 100 page technical specification and often do not have the technical vocabulary or communication skills to describe what they want and more importantly what they need. You literally have to paint a picture for them. The more visual it is the better the understanding will be and the better the feedback you will receive during the planning stage. Mockups make the proposed system seem real to the users for the first time. A good mockup will show all of the widgets on each screen and have an “Screen Mockups help end users to visualize the system design. Mockups make the proposed system seem real to the users for the first time.” explanation of what’s going on with the screen. One could use Visio for doing the screen mockups but an even better tool can be found at www.Balsamiq.com. We’re not affiliated with Balsamiq, but we especially like this tool because the mockups are super easy to make and look like hand drawings. Unlike a Visio drawing, a hand drawing-like screen design reinforces the concept that the user is looking at a mockup and not the final product. That’s important because if a mockup looks too real some users can get bogged down in things like color schemes and other minutia detail. At this stage you just want them focusing on functionality and flow not how pretty it looks. You need to get the users to buy into the solution early so you can verify the system will meet their needs. This strategy of involving the users early in the project produces a better product and reduces the natural resistance to change when the new system is fully rolled out. A user is much more likely to accept a new system that they helped to define. Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

6. Identify Integration Points Another part of your plan will be to identify all parts of integration. Often new systems do not happen in a vacuum. That is, they will need to retrieve data or pass data to some other software system that already exists. Each of these integration points needs to be identified; not only what data is to be transferred but also an explanation of how and when it is to be transferred. Sometimes, during the planning stage, the method of communication between two systems is completely unknown and requires a proof-of- concept prototype of passing data just to discover what’s possible. It’s much better to find out your proposed integration approach doesn’t work during the planning stage before you design a complete architecture around it. Some examples of integration would include:  Web Service calls: A web service is a method of bi-directional communication between two different software systems. They may be located in the same building or be separated by continents and don’t even have to use the same technology. The web service “publishes” the specifications of its interface so the system on the other end knows how to communicate with it. Think of a web service as a little program that’s in charge of transferring data between two systems and hiding all the complexity of the internet plumbing from the programmer.  Direct Database Access: This type of integration involves directly accessing the database of another system. If the purpose is only to read data from the other system then there aren’t any problems here. However if the other system needs to be updated, extreme caution must be exercised. If a database is updated directly it may create a problem with the integrity of the data if done incorrectly. For example, if the database design requires that 4 records be simultaneously created in 4 different tables when you add a new client record and you only create 1 of those records then you may get the database out of synch. This sort of problem is normally averted by calling a stored procedure that creates all 4 records at once. The greater the complexity of the database the more chance there is of creating a problem. So it is important to understand and define exactly how you are integrating with an existing database in a safe way.  Importing of files: Often direct integration with another system is not possible because of differing technologies, lack of accessibility, cost, etc. In those cases a 2 step process is the easiest solution: 1) Export the data from one system into flat files and 2) Import them into the other system. The file format of the exchange will need to be defined. In some systems this entire process of exporting and importing can be automated. “New systems often need to integrate with existing legacy systems or entities external to the company.” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

7. Write a Test Plan The lack of a test plan is why so many systems go live loaded with bugs. Each programmer needs to do unit testing on their individual part of the application but then it needs to be handed over to the testing team for end to end testing. This is because when testing, it is human nature to overlook details in an application that you wrote yourself because you’re too close to the problem. Programmers have a tendency to use the same test data over and over while they’re writing code. Having an independent tester ensures better quality. But how does the tester know what to test? That’s where the test plan comes in. It will describe how the application is supposed to work and what tests can be run to prove that it works as expected. The test plan spells out the criteria for user acceptance. 8. Identify Go Live Issues Some brand new systems can simply be turned on when ready. However others, especially ones that are tightly integrated with another system, may require a very complex go live procedure to prevent any down time in an existing live system. The entire process needs to be thought through, documented and contingencies identified should any unexpected problem arise during deployment. Go live plans are particularly important for sites that have high traffic, such as ecommerce sites. An outage of even a few minutes could cost many thousands of dollars in lost revenue. 9. Do Time Estimates This is one of the toughest parts of a software planning project because it requires you to look into your crystal ball and accurately predict the future. But it’s not impossible. Armed with a good planning methodology you can take a systematic approach to coming up with a realistic time estimate. First determine the rough number of man hours needed to complete the project. METHOD #1: SCREEN ESTIMATION One way to do this is to have a seasoned software developer look at all of the screens and estimate on a screen by screen basis the amount of time it will take to develop each screen. The complexity of each screen needs to be taken into consideration as well as the business rules and what’s happening in the database to make the screen function. Then additional time needs to be allocated for subsystems and programming tasks that do not have screen user interfaces. “The lack of a test plan is why so many systems go live loaded with bugs. “ “Go live plans are particularly important for sites that have high traffic, such as ecommerce sites.” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

All of these individual estimates can go into a spreadsheet and be tabulated. However beware of the pitfalls of estimating. Programmers are typically optimists and tend to say things like “I can bang that out in 4 hours!” 16 hours later they’re still putting on the final touches. This happens for several reasons:  The programmers can see the logic in their heads and thus it seems straightforward and easy. It’s human nature to underestimate because, as the saying goes, the devil’s in the details.  They don’t allow any time for testing.  They don’t allow time for integration & deployment.  They run into unexpected data or conditions that were not originally identified and they haven’t added time for unknowns that are sure to arise during development. There should always be a value of at least 15% added to any best guess project estimate to cover unknowns. One way to get to a better estimate is to have 2 or more senior developers independently define time estimates for the same list of programming tasks. Then call them into a meeting together to compare notes. Now, as you can image, this requires the developers to check their egos at the door and be willing to accept constructive criticism. Estimating is subjective and based on a programmer’s past experience so the numbers will vary somewhat. However, you’ll find that many of the numbers will be surprisingly close. But if one person says a particular screen will take 20 hours to develop and the other person says it will take 200 hours then that means one of them is wrong because of some false assumption they have about the system. A healthy discussion of that screen will get to the bottom of the discrepancy quickly and give you a much better estimate. METHOD #2 FUNCTION POINT ANALYSIS Another method of time estimation is the use of Function Point Analysis. This is a technique for measuring software in terms of the functionality it delivers. Each piece of functionality is identified and categorized. Complexity factors are applied to each function point. In the end the equations produce a number of man hours needed to complete the project. Some companies will use the two different time estimate methodologies mentioned above as a sanity check for one another. If the two methodologies produce wildly different numbers then all of the assumptions about the project should be scrutinized. 10. Schedule the Work Size up your developerresources and create a schedule.Now armed with the total number of man hours for the projectyou’ll be able to divide and conquer. Set prioritiesin the project thendivide the differentscreens and tasks amongst the team.Insettingprioritiesyou may want to ask the question“Whatis the “Armed with good planning methodologies you can take a systematic approach to creating realistic time estimates.” Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

minimum amount of functionality needed to bring the application to market or to go live?” This may cause you to divide the project into phases. If possible, go live with a reduced-feature phase I so that the organization can start reaping the benefits of the new system while phase II is being developed. Next map that to real calendar dates and don’t forget about holidays. Set specific milestone dates during the life of the project so that you can measure your success as you go. Remember, if you can’t measure it, you can’t manage it! So, how do you create a project schedule and capture the hundreds of details? Some people try to do this with Microsoft Excel but Excel wasn’t really designed for that purpose. It’s best to use an off-the-shelf tool like Microsoft Project. However, pretty much any reputable project management software package would suffice. Microsoft Project has been around for many years, since 1984 actually. As you can probably imagine, it’s a very, very mature product. It has features that make it easy for the novice as well as the most seasoned project planner. “The project schedule merges the time estimate with the actual calendar and resource availability info.” Example of a Software Project done in Microsoft Project Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

Planning a software development project can be a daunting process. But before you start, you need to give some thought as to how you’re going to manage the software development process. And like everything in life, there’s more than one way to solve the problem. There are two primary schools of thought for doing software development: Waterfall and Agile. Waterfall is a process whereby the entire project is specified up front, then written, then tested, bugs are fixed and then it’s deployed. This works great for small projects but as the size and complexity of the project grows it becomes increasingly difficult for the project stakeholders to understand the implications of thousands of details. This is especially so if the spec writing process lasts for months. As stakeholders dive deeper into the details they tend to change their minds about things specified earlier. Change management in Waterfall is difficult. Agile development methodology handles change better during the lifecycle of the software project. It accomplishes this by breaking the project into smaller “Waterfall defines the entire project up front whereas Agile breaks the project into smaller units where design and implementation happen in an iterative process .” “Choosing the right development partner will ensure success in your project.” units and having an iterative process that engages the stakeholders early and often. Design flaws are discovered earlier. Feedback goes immediately to the developer and is put into the next iteration. All of the same design work that is done in Waterfall still needs to Analysis & Design Implimentation Initial Planning Deploy Evaluation & Feedback Testing be done in Agile, it’s just done in more manageable, bite size chunks. Since the cycle time is shorter problems can be addressed while the design details are still fresh in everyone’s mind. With Waterfall there may be months between design of a given screen and its actual implementation. So it’s hard to remember all of the reasoning behind the original design. For more on Agile Development see: http://en.wikipedia.org/wiki/Agile_software_development Conclusion The number one reason for software project failure is poor planning. Following a process, weather Waterfall or Agile, forces you and your staff to completely think through everything that’s going to be built. Errors in architecture are significantly less expensive to fix earlier in the project so proper planning is crucial. What would happen if a high-rise building were constructed without fully designing the first floor? The project would be a disaster. The construction industry ensures quality and building safety by a very detailed process of project planning. Should we expect anything less from our mission critical software development projects? Working with seasoned software project planning experts will give you an edge and choosing the right development partner will ensure success in your project. Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

“Discipline is the bridge between goals and accomplishment” SMARTER DEVELOPMENT Experience & Discipline We have developed software for some of the most prestigious companies in the world: National Geographic IBM EDS Mack Trucks Texas Instruments NSTAR Electric & Gas Kimberly Clark Monsanto Agricultural Harris Corporation BAE Systems Elizabeth Arden Mary Kay Cosmetics Calvin Klein Cosmetics Ralston Foods Sara Lee Bakery Hershey Canada Cadbury Beverages Hormel Foods Corporation Perdue Farms J.M. Smucker Company Ocean Spray Cranberries Tootsie Rolls Industries Uncle Ben's McCormick & Company Lindor Chocolate Butterball Turkey Birds Eye Vegetables Reynolds Aluminum Pontiac Foods (Kroger) Dartmouth-Hitchcock Medical Center Dana Farber Cancer Institute Partner's Healthcare Caritas Christi Health Care Janssen Pharmaceutica Lonza Biologics Pfizer Animal Health GlaxoWellcome (UK) Bayer Corporation Ciba Self Medication Mohawk Fine Papers Haley & Aldrich Prestone Products State Street Research Informa Global Markets Kamakura Corporation Homesite Insurance Mass. Division of Insurance Mass. Board of Medicine Proper software development requires discipline and good planning brings order to the chaos. Call me today for a FREE IT Consultation (603) 726-5058 (my direct line) I will personally walk you through our proven process for making your ASP.NET Software project a success, delivering it on time and on budget. Don't risk failure. Call today. Lance Keene President Keene Systems, Inc. 603-726-5058 Lance@KeeneSystems.com What clients have to say about Keene Systems “Keene Systems developed a profitable e-commerce site and two powerful intranet applications for us. One was an editorial application for entering new books and updating the live site through a work flow-controlled process that included editor, publisher and author approvals. The second was for customer service, billing, and financial reporting and detailed activity monitoring. In all three cases, Keene Systems delivered outstanding turnkey systems that were flexible and open- ended.” David Wilcox, CEO, MeansBusiness, Inc. “Keene Systems enabled us to create an internal database- driven HR application that calculated employee bonuses and hid its complexity from our users. Although web based, the UI was as simple to use as a spreadsheet.” Nancy Spalding-Gray IT Manager State Street Research project on schedule and on budget.” Sharon Hershon IT Manager Partners Healthcare “The Bariatric database has proven to be a successful tool for our program. It is very smooth for all staff to navigate patient information, follow patient meeting attendance, as well as track patient weight loss. We will gladly work with Keene Systems in the future, as our needs change.” Shari Plourde Bariatric Coordinator Dartmouth Hitchcock Medical Center (Now BlackRock, Inc. a prominent Investment Management Firm) “To help us create an internal patient record-keeping system, Keene Systems provided the responsive service we needed, delivering the completed

How To Avoid Failure With Your ASP.NET Software Project?