What’s the Goal?
So, you’ve got a new software application in mind. You’ve interviewed a .NET application development company or two. Based on asking the right questions, you have selected the best you can find. Your choice seems to be a perfect fit in every way. Your project should run like a well-oiled machine. The reality is, you have interviewed them. They have not interviewed you. Since they are in the business of providing a service, it is not often that they will turn away a client. So, whether or not they think you are a good fit, you are now a member of their team. And as in other types of teams, the members expect all of its members to participate in order for a project to run smoothly, including you.
On a team each team member has their own roles and responsibilities. Unfortunately, there are some clients that don’t see themselves as part of the team. In their mind they are giving you a job to do and expect you to do it. Their first surprise is usually the need for you to provide the development team with a clear, concise goal for the project. What are you trying to achieve with the new .NET web application. What part of your process is not working? What outcome is expected from the change?. . . increased efficiency?. . . increased ROI? . . . scalability?. . . compatibility with new systems and applications? The goal is what sets the stage for how the overall project should run. It helps define the specifications and how the requirements are implemented. When there is no clear goal, different team members try to define them, based on assumptions they make. This can potentially lead to conflicting goals and thus, either an unhappy customer, an unhappy team or both.
Here are some examples of client/development team scenarios where goals are poorly defined:
Scenario One: You are updating an existing application that is decades old.
Goal: Update our old desktop application to a web based application.
Your company has been running the same application for the last 15 years. One of the things that we, as humans, are excellent at. . . . not changing. It is something that makes us uncomfortable. So, many clients want the latest .NET web application to look and feel like the application they had 15 years ago. Often times this is at the expense of the designers and developers not being able to do their jobs to the best of their ability and take pride in their work. It will also lead to an inferior product from a form/fit/function perspective. Technology has changed since the old application was built. There are new tools and widgets to make the user experience more efficient and enjoyable. Old technology for doing certain functions may not work well with new technology. Trying to work with a client that has their mind set in the past may become a continual battle for both the design team and developers. As a client, knowing change is difficult, keep an opened mind. Whether it’s reviewing designs or testing the product, new technology is there to make your job easier. Yes, it is unfamiliar. But the learning curve for use should be greatly reduced because of the improvements in technology.
If the client goal is to just allow the current application/website to be able to be used with the latest required technology/OS/email applications/browsers, than the goal for the development team should be just that. This does not mean that the team can not suggest additional goals that could be reached to benefit the client. But when doing so, it is best to provide clear concepts, with visuals (wireframes), and estimates for the changes.
From the client perspective, before taking the “don’t change” attitude, look at the most recent applications and websites that provide similar purposes or services. Keep an open mind. Ask questions about pros and cons of changes in technology so that you are comfortable with the change from a functionality perspective.
Scenario Two: Your goal is broad and not clearly defined.
An example of this may be to provide data to management on the status on the production floor.
This, in theory should make the job for developers easy. They can set their own plans and create an application they envision with a low bar for delivery. A good team will not accept this as a goal. They would push back for more details of who, what, why and when. They will not make assumptions based on the stated goal. Because the goal is broad, there are many ways it can be implemented. Without more details, what they estimate will not be accurate. Once the project is underway, the client will begin to add more detail and the scope will continue to increase and change. They may want a dashboard, import/export functionality, alerts, email notifications, pages for each line on the factory floor, etc. All of this is not in the original scope. All of this takes time to develop. When the client begins to be billed, the sticker shock will hit when they realize that this project is not what they budgeted for. Sometimes they understand that each of these are added enhancements to the original broad scope. Other times they do not. If they do not, then you have an unhappy client. And an unhappy team member impacts all team members.
While it is the responsibility of the client to make sure they have a clear goal in mind, it is also the responsibility of the .NET application development company to make sure that all changes in scope are documented, estimates sent and approved. This needs to be done before the work is actually done so that the client has the chance to digest it and make conscious decisions. But before they get to that stage, the development team has a responsibility to get clear goals.
Scenario Three: Your goal is HUGE!
Your team has just budgeted a large amount of money to automate the company. So every system needs to be updated. Processes that are still manual need to be automated. And the best part of all this is that you don’t have to go and ask for the money. So with no financial restrictions, what could go wrong? Time, Money, Quality. . . . pick two. Since you have one of these already on your side that leaves Time OR Quality. You are in charge of the project, and everyone in the company from top to bottom is watching, so making the right decision is important. Time, get it done quickly. Won’t everyone be impressed? But if the quality is bad fast means little. A few extra months saved for delivering a solution that will be used daily over several years, time is not on your side. That leaves quality. And can quality be guaranteed even with all the money in the world?
But wait, you have all the money you need to get this project done right. So you can hire the best developers. You can put several on the project and as many QA people on to test as you need. This would increase the time and keep the quality. This is a win-win situation. Or is it?
In this scenario, the best option may be to break the project into manageable chunks. Prioritize the requirements and divide them into logical modules. Your development team can help with this. Once that is done, since you have hired the best team, start with one or two complementary modules that can be worked on in parallel. Perfect them, being sure to have a clear, manageable change control process. Ensure that the interactions between the two modules are working, with heavy duty QA. Once you have completed the one or two modules, release them for internal testing, and finally go-live. Only after a few weeks of use should the team start work on the next set of modules.
There are other challenging scenarios that can occur based on how you set your goals for a project. Keep in mind, it is your responsibility as a client to set them. The .NET web development team does not know your business and cannot read your mind. If you have clear goals and communicate them well, the development team will welcome you as a star player on the team. And with that comes a smooth running, efficient, high quality project.
To learn more about the importance of eliminating human error in your operations, please download the eBook titled "How to Automate Business Process in 7 Smart Steps."
