Pulsar Application Management Methodology

Pulsar has developed his own project management methodology by integrating the practical experience of our consultants with different methodologies and tools: waterfall approach against cyclic RAD approach, Earned Value analysis, Oracle-CDM (custom development method), Belgacom-Promis project methodology.

This methodology, after slight adaptation depending on the project specificity, is followed during each fixed-price project, helping us to deliver on time and on budget. The strict compliance with this methodology allows us to reduce the risks contingencies and the development time. This let us the ability to propose better prices to the customer and be more competitive on the market.
This Methodology is always subject to changes, as every new experience we acquire on projects may be integrated in the methodology

We will present here all the phases of the methodology, with the mention of all the standards documents associated with each phase. Each document has its own template present in the Centralized Standard Pulsar Project Structure.

File Naming Convention

The Methodology fixes a number of standard documents that must be used in each project following the needs. New documents, specific to the project, can be created when needed. If a document repeats in several projects, it can be included in the methodology standard documents.

The file naming convention is intended to fix the rules for files names definition. It is applied for all standard documents described later on in the methodology AND MUST BE APPLIED FOR EACH NEW DOCUMENT NECESSARY FOR A SPECIFIC PROJECT.

Each new document must in addition be formatted using the templates “.dot” found in the Pulsar Methodology Directory.
The following files name categories can occur in a project/application:

Documents and database-related filenames;
Sources and Runtime filenames

General Rules

Each name contains several ‘words’ explaining the content of the document. Some of the ‘words’ are fixed by the methodology (methodology-related acronyms), other are specific to the project but are following the same naming rules.

The methodology-related acronyms are in full capital letters. The first one is mandatory and is placed in the beginning of the name. The other possible are just after, separated by dash. Example: ARC-DIAGRAM -MyClient-MyProject-MyTopic-Doc_Version.vsd

Except these acronyms, the first letter of each word must be a capital letter. All other letters must be lowercase. If a name is made of two or more non-separated words or separated by dash/underscore/plus/minus/equal, the same rule apply. This makes the name more readable.

The files extensions must be adapted following the specific tool used to produce the file. Example: if a file is edited with Notepad, the extension will be ‘txt’.

In the naming the following special characters are used:

“<” and “>”: are delimiting a mandatory information that is adapted when used
“[“ and “]”: are delimiting a non-mandatory information that is adapted when used
All other characters, “-“, “.”, <methodology-related acronyms>, are mandatory

The Topic and the version are not always mandatory, and can be added to whatever document, following the needs.

The file version is very often different from the application version. Generally, the v1.0 is the same for both (meaning the file version 1.0 is delivered with the application version 1.0). This allows changing the file version only when the content changes (if not, identical files would be re-numbered with the versions and this is not practical).

Documents and Database-Related Files Naming Convention

These documents are often used outside the frame of the project either by customer’s representative dealing with specific topics (procurement, proposal, project management, etc) or by administrators implementing the application in their specific IT environment. Thus, they need to specify as much as possible information in the name. General naming structure:
<Doc_Type>-<Client>-<Project>-[Topic]-[Doc_Version].<File_Type>

Doc_Type is always one or more methodology-related acronyms. The list, in alphabetical order, for the first one, mandatory: ARC, ARCREQ, BUSREQ, CLASS, DB, DBLOAD, DBSTRU, DEPLOY, EVAL, GUI, HELP, INST, MAINT, MM, PACK, PROJ, PROP, REQ, TEC, TSK+ENH, TEST, UMAN, VERSION. The list, in alphabetical order, for the second one, not-mandatory: AGREE, CHANGES, DIAGRAM, GRANT, FOLLOWUP, IDX, SEQ, SITEMAP, SYN, PLAN, PROC, PROGRESS, TAB, TRACE, TRIG.
Client is the client name;
Project is the project name;
Doc_Version is the document version (and not the application version!);
File_Type can be by example: doc, xls, pdf, rtf, ppt, xsd, cdm, pdm;
Topic is used to precise more the content of the document. Typically, a topic could be:
- An application module name
- An application part
- A specific Subject
- Or, more generally, explanations about the document content in one or two words.

Remark: Some documents have not this field, because in general cases, it is not useful. However, if you need, you can add a Topic field for these documents.

Sources and Runtime Files Naming Convention

These documents are always used inside the project or application structure and thus, do not need to specify information like project name, client name, etc. General naming structure (compiled, executable, configuration, libraries, scripts (javascript, vbscript, shell, etc), interpretable (html, xml, xsl, css, etc)):
[Topic].<File_Type>

File_type could be types like java, css, xml, properties, etc.
Topic has the same meaning as in documents and database-related convention (above).

Pulsar Application Management Methodology - Generals

In the ‘good old time’ of project management, a waterfall approach was often used because of its simplicity of understanding and management: each phase takes place after the end of the previous one. All the Gantt chart diagramming for project management is based on this idea. Three major disadvantages can be highlighted for this classical project management method:

The customer need to correctly and completely define its requirements in the beginning. Please note that for implementers/project team this is rather an enormous advantage, because it allows them to organize the project phases, modules and content without ulterior changes. The milestone and budget killers are the changes during the project phases. Later the changes arise, bigger the impact in the project plan. A Change Management Process should then take place.
Respecting the timelines in this approach requires ensuring slots of time between phases to allow synchronizing the phases end before starting a new phase. This leads to a longer time for the whole project.
Each error or change taking place in one or the other phase impact on all the subsequent phases and need a new complete cycle (starting on the error or change point) to correct/integrate it.

‘Bad’ experiences coming up from these disadvantages have led experts in project management to migrate to what we call today RAD approach (Rapid Application Development). The main property of this method is that it allows a prototyping approach instead of a waterfall approach. The main behavior is to create a first prototype, submit it to the customer, change it in a second version, submit again, etc.

Although very handy for the customers (no initial complete requirements are needed anymore) this approach is much more risky for Fixed Price projects (price and deadline agreed and fixed in the beginning of the project).

In order to cope with advantages of both approaches, and also to minimize the out-of-budget/out-of-planning risks Pulsar promote a combined approach:

Management of phases by function/module
Controlled Change Process Management

Phases & Modules Management

The Projects we develop are usually split in several functions/modules, and for each function/module we apply a waterfall approach. This way of working allows us to be very flexible in terms of phases overlaps. A general rule indicates that some phases can overlap in each function/module. However, there are exceptions to this general rule, regarding the following phases:

The development phases always starts at the end of the Technical Analysis.
The Internal Integration Tests Phase always starts at the end of the Unit Testing

Those statements are valid for any Application Module taken on its own.
In the Global Project Diagram however, we can notice that the Technical Analysis Phase and the Development Phase may overlap. This can be explained by the fact that as the project is split in various modules, the development phase for Module 1 may be started while the technical analysis phase for Module 2 is not yet finished. When consolidating the various modules planning on a Global Project planning, overlap may then arise.
However, a major exception to the overlapping rule occurs also in the Global Project Diagram: the Unit Testing Phase and the Internal Integration Test phase never overlaps. All Modules must be developed and “Unit Tested” before the Internal Integration Testing phase can start.
You will find here under a diagram presenting the whole application development cycle as it is managed at Pulsar. We have taken an example with a project composed of 3 Modules. At the Top of the diagram, you can see the Global Project Phases.

Controlled Changes Process Management

For fixed price projects, and more generally for any project, it is critical nowadays to keep track and control the changes during the project. We could certainly object that the requirements are fixed in the beginning and should not change, but this is not realistic. Requirements DO change, and a good project manager cannot ignore these changes for several reasons:

These changes are sometime or often reflecting the market changes and the project MUST be adapted to the market requirements
If the beneficiary of the project changes his mind and the project does not take them in account, the resulting application could be un-useful and unused.
If no flexibility is given to changes during a fixed price project, even if contractually his right, the project manager risk to lose the customer for the next projects.

Although these are strong reasons to let changes happens, remember that changes are budget and deadlines killers. The solution is a controlled change process management. Pulsar implements this concept thru the following rules:

For each module/function of the application, but also for several functions together a finalized layout prototype is created and shown to the customer/beneficiary before the development phase. Also called GUI (graphical user interface), mock-up, HMI (human machine interface), this prototype is as closed to the final version as possible and lets the customer have in the analysis phase a precise idea of what he will get at the end of the project.
Several cycles of acceptance/adaptations between the project team and the beneficiary allow ‘fixing’ this GUI in analysis phase and avoiding a big amount of possible conflicts during the acceptance phase. Indeed, statistics shows that most part of the remarks/problems found by the accepters of the customers in the acceptance phase are related to the GUI and not to the functions themselves. These cyclic modifications of the GUI are easier to do on a static prototype than to the final application. 2-3 cycles are generally foreseen by Pulsar during the analysis.
Based on the first requirements definition, a good communication between the project team analysts and the beneficiary acceptors allow agreeing case-by-case if it is a requirements changes or not. If yes, then several options are possible and must be discussed and agreed:
- It is a small change and Pulsar agrees to do it in the fixed price framework.
- It is not a small change and the customer agrees to do it later, after the first version of the tool
- It is not a small change but is needed by the customer in the first phase, and then he agrees to increase the budget of the project. Pulsar then re-evaluates the milestones and the deadline and an agreement takes place on the new planning (often the planning can be kept by adding resources to the project).
- Pulsar keeps up-to-date a list of possible enhancements during the whole lifecycle of the project and sends it regularly to the customer. This clarifies what was agreed not to be part of the project, but also lets the customer evaluate on this list, by comparison, the priorities, the functional and technical impacts (explained by Pulsar), the proposed solutions, the necessary man-days to do it, etc
- Pulsar often propose to the customer, if appropriate, a maintenance agreement allowing implementing these enhancements but also assuring a second line support, bug-fixing, etc.

Documents Delivered to the customer

During the Project, part of the documents is delivered to the client. The application content related documents that are generally delivered to the customer are:

GUI Document (GUI)
Architecture Document if needed (ARC)
Database Document (DB)
Installation Document (INST)

The application management related documents that are generally delivered to the customer are:

Project proposal (PROP)
Project Plan and/or work breakdown structure and tasks (PLAN)
Meeting Minutes (MM)
Project Progress Report, at client request (PROJ-PROGRESS)
Maintenance agreement (MAINT-AGREE) and maintenance activity tracing (MAINT-TRACE)
Maintenance Follow-up Report, at client request (MAINT-FOLLOWUP)

At client request, other documents can be made and must be estimated in the project scope (if fixed price). Even if not specifically requested, some other documents are done at Pulsar site for internal documentation purposes. When they exist, they can be made available to customer at simple request. Example: TEC, CLASS.