Our process is centered on Project Management and Rapid Development methods for all projects, both print and solution development. Processing your print media solutions requires less steps.


Initial Meeting

It all begins with the initial meeting where we gather information for your solution:

  • Initial Requirements
  • Design Elements
  • Survey of available Corporation Information & Db's

During this initial meeting we discuss, at high levels, what is to be achieved and the expected results with the project. We offer some suggestions or possible elements that may be included in the project.

Review and Refinement

IDS then reviews the elements and requirements and develops a rough draft of the timeline and project goals, requirements, specifications and deliverables. Then we meet and refine the project so each side understands the scope and elements required.

At this meeting we may need to adjust and refine the scope so that all requirements, including budget are being met. This process continues until resolutions are achieved.

As an outcome of these meetings, we will have a more definitive project plan with costs and deliverables defined.

Once an agreement is made, the project is launched and we officially begin the development process.

Project Start

Once the project is started, we make weekly status and progress reports. Along the way, we offer complete backups of the source and content to our clients, as they require.

As required by the size of the project, IDS may have to first develop a complete requirements specifications and project management documentation. This is typically reserved for larger projects.

Proto-type and Acceptance

One of our first goals is a proto-type. From this we gain initial acceptance and sign off to proceed or make changes. We first develop several proto-types for client review. At this point, the client can say what they like and don't like in these prototypes. It is very typical for a client to choose a color scheme from one and a design element from another and combine them all into a single design. On some projects there are many different areas that may require proto-types and all of this would be spelled out in the requirement specifications.

Development Site – Client View

During the development process, we will elect to publish various works in-progress for review and comments. These are sent to a web site that has a higher level of access control. So only those who we choose can view the information. During various milestones, we will also publish this information to the same site for review and feedback.

In-house Testing

During all phases, we are testing and making corrections based upon the usability and issues found. These are corrected as part of the overall process, but at times, some of the issues may cause a change in scope or level of effort change. This occurs because the initial understanding of a given feature may not have been completely understood; only through actual creation or testing in the real environment can the true nature of the issue or scope be derived.

Initial Project Completion – Client Testing Start

At this point, everything is operational and tested based upon the deliverable schedule. Client information, third party information, and IDS information have all been integrated.

The solution is again released into the test development area and the client begins acceptance testing.

During the testing cycle, the client can comment on any sections and issues that occur. They are given tools that allow IDS quick isolation of issues and problems.

All corrections are logged and corrected as quickly as possible and the solution is updated as testing continues. This testing process continues until the product is determined to be working by the client.

Product Launch or Product Live

Once the client has accepted the solution, it is then scheduled for configuration into the final production environment and access granted to the end users.

As part of this final configuration, testing of the product must be done again as there may be some small issue that is different in the testing environment than the production environment. Normally these tests are abbreviated, but nonetheless required to ensure the highest of quality in the final product.

Staged Implementation & Support.

IDS, will be there to support the products that it creates. After a product is released, some small issues or additional functionality needs will arise. Changes to the project will be addressed and scheduled as required support of the product continues.

Often, larger products have a layered approach to implementing various functions and features. A smaller set of functions are implemented, tested, then published live. Then the next set implemented and the development cycle continues until all of the features are implemented. This allows quick and early adoption of the product with reduced features and ultimate faster end user feedback.

Keeping on Track…

While IDS makes every effort to complete projects in a timely manner, many different issues can hamper us from maintaining the timeline. Here are some of the issues that we have found that affect the deliverable dates of any project, large or small:

One point of Contact – This allows IDS to focus all contact through a single responsible person whose job it is to insure that the deliverables are met.

Client Scope Changes – Many times, projects are started and the initial scope is not complete. Having a complete understanding of what the requirements are is critical to projecting correct time estimates.

Delivery of Content and Information - Late delivery of information has a direct effect on timely delivery. We can typically not proceed without the specific set of information that is missing. We will continue on with other portions of the project where possible, but we need the information quickly.

Feedback – Overall feedback is important to making modifications. If we don't know the feedback we cannot correct inaccuracies promptly.

Testing Results Feedback – Testing feedback is important to making the product stable, and obtaining good information on how and where the problem occurred is critical to our ability to reproduce the problem and correct the issue.

Incomplete Initial Understanding or Scope – Sometimes there are hidden requirements that are never completely understood. Only through an actual attempt to create and / or testing the problem in a real environment can the true nature of the issue be derived. These issues are typically very few, but they can and do occur and may cause a Scope or Level of Effort Changes.

 
Main
Philosophy
Testimonials
About Us
Our Process