The Kick Off is one of the crucial components of the project. It is primarily about introductions. We’ll give you a little overview of our history and our ethos, but we try to keep this part short! It would also be great if you could let us know a little about you too. Next is to introduce all the members of the project team, both our members and yours. We should all leave the meeting with a firm understanding of who’s who and the various responsibilities for the project. We use various online applications to support every project we undertake and we will introduce people to these. We also hope to get some idea of what the Product Vision is, as we feel that this is vital to give people a clear understanding of what needs to be accomplished. That’s pretty much it. Start simple.
You need to bring the people that will be involved on the project within your company and an open attitude. You don’t need to bring a notepad, we will take notes and do all the chasing (if there is any to be done). We genuinely want to build you a great product and we want to meet the people we will be working with. Ensuring that all the project team meet helps to build a good relationship right from the start.
A Brainstorming Session is not as bad as it seems. At this session we will try to establish the ideas. What will this product do? What are the customer needs? What needs to be there for the application to be useful? What vision does this product have? What is the core functionality? The primary goal is to take the ideas in your head and get them out onto paper. Don’t worry we run this session, we just need your brain power. We use various tools to capture these ideas, ranging from Mind Mapping to a simple whiteboard.
Please note if you can think of a better description than Brainstorming please let us know, we would love to find a better one!
We are primarily concerned with getting what’s in your head out and onto paper. All we ask is that you come into the session having spent time thinking about it. If that means making some notes before coming into the meeting, then that’s great. Anything that allows the ideas to come out of your head and onto paper is just fine. The only things that we try to avoid are long functional specifications that have been gathering dust. We feel that the problem with these documents is that they stifle rather than enable the process.
To build you an application, we need certain things from you and its best to get this up front. In their enthusiasm, development companies can forget to gather this information and they use the wrong logo, incorrect colour schemes and miss off vital legal statements. So the application might function perfectly, but your marketing and legal department will have issues! This set of tasks is to try and get hold of the right content / media / development related information at an early stage so we can avoid making obvious mistakes further down the line. So we will ask for logos, corporate colour schemes and ask you to notify us of any legal issues you need covered. We will also determine who is responsible for installations and other development related tasks. But don’t panic if you don’t have it all right from the start, we can work on it together!
The Storyboard is a way of communicating a rough idea of how the application will work. It is also a great way for you to see that we have understood what you want designed. Many companies will rush ahead and develop a prototype, missing out this stage. We feel that this is a really important step as it allows you to comment very early on in the process. We can then go back and rework the Storyboard. If everything goes to plan and you love the Storyboard it gives you a warm feeling inside knowing that we have understood what you want. It gives us a good indication that we are on the right path and it keeps everyone on the same page, so to speak.
The Storyboard is our way of explaining to you that we understand your requirements. You have the opportunity to review the storyboard and give your feedback. We will not have got everything 100% right, so we expect it. We can then go back, revise the storyboard and repeat the process. Don’t worry we factor in time to the project for any changes you need to be made.
Unfortunately not! We understand that giving tasks a priority is one of the hardest parts of a project, however it has to be done. To make things easier we try to have a prioritisation session as early as possible. The first session is to get a better idea of what is vital to your company so we can put extra brain power into it during development. A painful truth is that if everything was top priority developers will start with the easiest tasks. Trust us, we have seen this too many times! Giving a priority ensures that we work on the tasks in the right order for you. But don’t think that the list is fixed, we see the priority list as something that the customer should and will change in a fluid manner. If a task has not been developed yet, feel free to move it up and down the list if you need to.
It is our responsibility, so don’t worry. Simply put, an Application Pattern is a process that your application needs to fulfil for it to function as you expect e.g. It could be as simple as a user creating and saving a record in the application. Various things come out from this process. But these patterns can subsequently trigger responses from you, like “Heh, they shouldn’t be able to save without filling in the date field”. As you can see this helps all of us to discover those little extra pieces of requirement.
Well that depends. Sometimes they could be in the form of a flow chart, with a set of processes mapped out. Alternatively they might be sketches with an accompanying flow chart. Essentially whatever gets the point across and enables confirmation that the pattern is right.
The Data Design is our way of telling you how we will store your data in the application. If it is within a SQL database we will present you with a series of Entity Relationship Diagrams. We also like to Model the data and we will also show you representations of these.
The Interface is what you look at everyday. For some people it IS the application. At an early stage in the project we will attempt to come up with rough Html screens (for web based applications) so that you can see and feel the application. We have found that we get an amazing amount of quality feedback from these layouts because people can visualise what the application might look like.
This is when we are working away at turning the Data Design into a set of tables, plumbing the code into the UI Layouts and applying the Application Patterns using code. We will have created a set of tasks that we have to accomplish in a given week and these are stored in the Project Management application that you use to follow progress of the project. You will see these tasks ticked off as we go along. You can also pick up the phone or email us, it’s not a problem. However if you have something material to input, we encourage you to do this in the Project Management application as this is where we always look first.
Once we have got to a stage where we need you to test the application, we will release what we have done. This release will be to an agreed location for you to test. We will update you on where we have got to, what is in the release and what we need you to test. At this stage we want you to use the application and give us feedback. We can then factor this into the next release along with the next set of project tasks.
We test every feature that we develop and try to eliminate most of the obvious issues before you start to test. We will also give you an internally signed off copy of the application for you to test. This copy will have a set of notes accompanying it with a list of the enhancements / fixes that have been applied to it. However we cannot resolve everything, so there will be issues that you discover when you test the application. As long as they are fed back to us we can then work on resolving them for you.
A Task is a documented project deliverable. An Issue is something that we / or you have discovered during testing. Essentially they are both tasks that we have to provide solutions for.
We like you to use our Project Management application to submit feedback. If this feedback is a bug you would create a Message with a category of “Bug tracking”. We then get notified and work on a fix for you.
We generally install the application for you, but this can also be done by your internal staff. Where the application is installed is ultimately determined on what type of application we are building. These questions are answered during the Gather Client Content process described above.
Hopefully everyone is happy and you give the go ahead to Go Live. In reality we like to give you a document listing the functionality that the application supports and a list of any known issues (if any). You are then signing off on this document. This ensures we have a concrete basis to work from. It sounds onerous but we try to keep it simple and concise.
© 2009-2012 UBQO Limited, all rights reserved.
Sitemap | Privacy | Disclaimer | Copyright
