Welcome to the RIAMS customer guide book!
While reading process guides is one our team’s favorite tasks, we realize there are many activities you would rather be doing. We’ve tried to keep it short for that reason, covering project discovery, app building and billing and we can promise it will help us save time down the road. If you have any feedback, please send it to firstname.lastname@example.org, we definitely value the input as it helps us improve our process.
At the beginning of any client engagement, we like to answer three questions:
Whatever our role with your company might be, from providing advising to building apps, we want to ensure our work directly contributes to you achieving your goals. These three questions provide the foundation for delivering successful projects and building great relationships and is ultimately what this guide is used to discover.
Discovery is all about understanding how our products, services, or advising align with your goals. This phase sets the tempo for the entire project and helps both teams focus on solving the right problem.
Before a project starts, we will schedule a meeting (in person if possible) to introduce our team, talk about our process and define the projects value.
Understanding your projects value lets our team make educated decisions as we move through app development. In short, we want to ensure that the code and features we are creating directly impact the value your project needs to deliver. Writing down the soft and hard benefits provides our teams with a shared understanding of what the project should accomplish.
For example, imagine you want to extend your invoicing system to mobile users. The project value might be defined as:
“By creating invoices at the point of sale, we reduce data entry mistakes by 50% and deliver feedback to our customers instantly, improving long term customer relations. Over 5 years, we believe point of sale invoicing could reduce the company costs by $50,000”
This statement helps accomplish a number of things.
User stories (Functional requirements) describe what the product should do in the hands of your end users.
Non-functional stories describe what the product needs to work (ex: servers, software updates, version requirements), quality of service levels, etc and will be described later.
Appendix A describes how to write quality user stories and provides examples.
After our initial meeting, we will schedule time to flush out the product requirements and write the user stories.
Our team commits to actively maintaining the stories for the duration of a project. This helps ensure the stories represent the shared knowledge between our teams of how the product will function. These stories are used for acceptance testing and defining future enhancements and bugs.
Here are a few important points about story creation:
Wireframes are the app blueprints that help visualize how the application will function. We have found that wireframes greatly reduce any confusion around the user stories.
Creating a wireframe involves defining a layout and adding in features, elements for copy, navigation and functional notes on how the site or application will operate. These mockups are an artifact of story creation and will be stored along with the user stories.
Here are a few important points on wireframes:
A wireframe may look similar to this.
Where your application will be hosted after going live is an important decision to make during the planning phases. Depending on the complexity of the application, one hosting location may not be as well suited as another.
If your company already has internal, or cloud based hosting, we will work with that system if the technology allows for it. If not, we make the following recommendations based on technology used.
|WordPress Marketing Site||http://wpengine.com/||Monthly: $29 - $250 +|
|SaaS Application||http://www.windowsazure.com/||Varies on Load – Min: $200|
|Linux Apps||http://www.windowsazure.com/||Varies on Load – Min: $200|
Pricing will increase significantly as expected and real loads increase on your application. It is important to note, that during a development phase you will generally be running two of the same hosting providers, one for testing and one for deploying live release code.
Along with infrastructure and hosting for your application, there are a number of other non-functional requirements we want to be aware of. Non-functional requirements are any items the application needs to run, outside of the how the application will be used.
In Appendix B, we include a helpful list of questions to better understand your non-functional requirements based on the type of app (mobile, web, etc).
Building the app is an exciting stage where user stories are transformed into a working product. Our team is a big believer in delivering app changes as quickly as possible to our clients. Delivery working code frequently helps our teams discover problems before the end of a project and manage change.
Project complexity drives the number of milestones in a project. A simple app, with a short estimated timeframe for delivery may have no milestones, other than complete the defined user stores, fix bugs and handoff code. When the complexity increases, we break down the milestones based on the most valuable feature sets. Again, we want to deliver the features that will provide your business the most value first.
Milestones serve a number of purposes to our team.
Please note that our team makes a commitment to always work on your next milestone if you were satisfied with the previous work. You are always free to take what we’ve created and hand it off to a different development team at the end of a milestone. We frame our contractual obligation to a set of user stories for a given milestone.
User stories attempt to identify what features provide the most value to you and your customers. As we deliver working software for you to test, stories will change as our shared understanding and expectations of the end product evolve.
Our team has embraced that this change is inevitable and healthy for the product. The most critical issue is to capture that change early and make sure it is reflected in user stories and milestones.
We accomplish this by pushing working user stories to a development server (for web & web mobile apps) weekly (or more frequently if changes are small). For mobile Android applications, we deliver a weekly APK file to install and test with.
Your team can then provide feedback and bug tracking through the UserVoice account we setup.
Toward the end of the current milestone, we will schedule time with you to review what bugs and enhancements may have been entered into the UserVoice. Enhancements, or new stories, can then be incorporated into the project.
It is important to note that app cost can still be managed by removing undeveloped downstream features and incorporating the more valuable new stories. What stories we add or remove will be agreed on by both of our teams prior to making changes.
Along with the working software, weekly we will provide you with the following updates through an email.
Meetings, either by phone or in person will be scheduled as needed to address any outstanding items.
Managing cost is one of the primary concerns for our clients. Often times, large projects need approval from a board, upper management or other stakeholders in the company. We have found the some projects can be accurately estimated with a fixed bid cost and others cannot. Before we explain how we determine the billing method, it is important to understand the three different ways we can bill.
For example, we might say for $5,000 we will complete story A, B and C over the next month. We continue this process until your end goal is reached, or you wish to end the work.
There are two factors we use to determine the billing method.
Let’s take a look at a few examples.
With Client A, the risk of changes is low and our company can provide a fixed bid we feel confident in. Client B also has detailed user stories, however the complexity of the project (time and features) is much higher. We know in this scenario that changes will occur in the project and we need to select a billing approach that reflects that change. In the Client C’s case, there is a long term vision for the product and it is highly complex. New requirements can be driven by each successive release of the software.
Depending on how solid those short term requirements are, we would choose between a Hybrid or Day Rate approach.
As a general rule of thumb, our team uses a hybrid approach for projects with estimated time horizons longer than a month.
We definitely understand your need to control costs. With the Hybrid approach, this can be more problematic than a fixed bid. When using the Hybrid method, we will provide an estimate on the price range for the project. This range is subject to change as the project evolves and is highly dependent on the project complexity.
Our team believes strongly in choosing the correct billing strategy based on the clients long term requirements and value proposition. Choosing a fixed bid approach, where complexity is high, results in bids where so much risk is baked into the price that the total cost often exceeds the value that you are going to derive from the project.
For some, this approach will not be a good fit for their project. We are happy to put you in contact with other development shops that may provide a better overall solution to your problem.
The template for our user stories is based on articles from Joel Splosky at Fog Creek Software. The blog post on specs can be found here (http://www.joelonsoftware.com/articles/fog0000000036.html)
This story below covers the login in process for a user in a SaaS application. This particular story is heavily security related and makes notes of particular technical implications. The story from the perspective of a user named Mike who owns the SaaS application.
|Actor||Mike – Administrator|
Mike is the owner of a SAAS application and acts as an administrator for managing tenants. Mike needs a way to access the main dashboard of the application, by entering his email and password. Successful login will provide Mike’s application in the browser with an authenticator token that is used to ensure Mike is the currently logged in user.
Scenario 1: Mike navigates to http://owner.appname/admin and is presented with the login screen. He enters the correct username (email) and password and hits submit. The application authenticates Mike and presents the dashboard screen. The authenticator token is stored in a cookie. (TODO: or somewhere in client side memory)
Scenario 2: Mike enters the incorrect username (email) and password and hits submit. An error overlay is displayed, describing that the username or password is incorrect with a link to retrieve the password (TODO: need to investigate the security here). The error message does not indicate if the username or password was incorrect to prevent interrogatory adversaries from finding out valid usernames.
Function Specs - http://www.joelonsoftware.com/articles/fog0000000036.html