A business analysis project may be required to identify business processes and/or related information flows. Process and information analysis projects should start with a formal and conclusive set of requirements which scope the project to the millimeter. What should the project or related products deliver to the customer and, even more important, what will it not deliver? In practice, customer expectations and project progress run parallel up to 90% of the finish line, but then grow apart. Many projects exceed their timelines solely because the customer and the project team differ in views on the end result, dating back to inadequate agreements at the start line.

Functional requirement documentation
One result of the business analysis project may be the need for a process or data automation project. My functional requirements documentation has been used by large organisations: it freezes the project scope in every essential detail and formalises the project delivery in 4 levels:

1. High level: the basic building blocks of the solution and their expected output
2. User: translation of blocks into use cases: delivery from a user perspective
3. Functional: non-technical detailing of each and every functional component of each use case
4. Non functional: environmental, infrastructural and human requirements
5. Customer communication and expectation management throughout the document production, as well as formal customer sign off on the final requirements, are included in every project.

Enterprise Resource Planning
Alternatively to a tailor made automation project, the business analysis result may display the need for some level of Enterprise Resource Planning (ERP). I have developed multiple online administration systems for small and mid size commercial organisations as well as NGO’s. More information on my ERP services can be provided upon request. Please send me an email.

The word “prototyping” has many different meanings. In my context, it means a desktop or browser based prototype of an application in conception. In many cases an interactive functional design (read more…) may do the trick but in some cases the desired application is too complex to depend on a design document alone. Perhaps the specific environmental requirements or infrastructure dictate that the costs of the eventual application are extremely high and no risks can be taken going the wrong way with the design.

My solution
My prototypes are usually developed in standard office type database systems and may consist of two different components:

• Front office: a desktop (MS Access/VBA) or browser (PHP / Javascript) replica of the desired application, which features all of the desired functionality: user authorisation and role model, grid and detail information pages, event driven workflow, automated system emails and corporate design styles.
• Back office: a local server MySQL replica of the database model showing table relations, referential integrity, query results and other relational database output.

A combination of these two will create a “near life” experience of the envisaged application… but at a mere fraction of the cost. It will create the critical mass required for convincing your project stakeholders and, most importantly, your budget manager.

Large organisations typically use centralised comprehensive database systems, managed by an IT services department and developed by an offshore organisation. Development cycles are long and require complex budget approval flows. Management information needs at departmental level are often overlooked, resulting in employees working with inadequate and outdated information, stored in all kinds of private spreadsheets and documents. Accessibility of information is low, aggregation of information is difficult and version management virtually impossible.

My solution
I develop desktop or browser based management information tools in standard office type database environments that centralise and present departmental management information, typically targeted at an audience of 10 to 1000 people. These tools operate directly on the central databases (SQL, Oracle), or use real time synchronous replications of central data. Information needs can be tailored exactly to departmental needs, automated reporting provides quick access and distribution of data and development cycles are short and fast.

Product features

• Departmental level management information based on central data
• High speed role based accessibility and portability of data
• Configurable automated reporting and distribution of information
• Tailor made functionality in short and fast development cycles
• Data security

Like with other project components in the latter phases of the project, production of end user manuals is an activity which is often overlooked or under staffed. Reading manuals is far from a favourite activity for many of the end users involved. Therefore, producing an end user manual which is to the point, easily readable and comfortable in use is a task not mastered by anyone.

Readable manuals
During various assignments I have successfully produced manuals for IT related projects and software applications. My approach is transparent. Before actually starting the manual, I produce a document architecture plan, which is then presented to the customer for signoff. The architecture reads and looks like the end product – with indexes, references, glossaries and layout – but without the actual content. Even fonts and colors, corporate styles, presentation formats (e.g. ratio text/images) are discussed and presented first. Only after full mutual agreement on the approach, the production of the manual will start.

Training
A set of manuals alone will not guarantee a successful acceptance of your new IT or ERP system in your organisation. I conduct one-on-one or classroom based technical trainings, based on your or my documentation and presentation materials.