Information Systems:Managing software development projects (Official Guide)

This article specifies guidelines that will be followed when undertaking a software development project at uniPHARM.

General Steps

Below describes the general phases of a project following its approval by the steering committee.

1. Initial meeting is held to discuss business needs and user requirements. Business and technical owners are assigned. A decision is made to develop the project in-house or to outsource the development. Either way, development should abide by the principles of the Developer's Guide, found here.
2. One or multiple Trello boards are created to facilitate collaboration and project task-management. Separate boards can be created for the planning and technical implementation of the project. Access is provisioned to necessary team members.
3. Business needs from the meeting are translated into a technical outline of the project by the IT/technical team. Depending on the scope of the project, this can be in a separate Word document (where requirements are more fixed), or done within a Trello board dedicated to the implementation of the project. When working with development consultants, this outline should be agreed upon by IT and the developers prior to starting any work, not as an unchanging work order, but rather as the framework upon which the software will be developed. Other members involved in the project should also be made aware of (and sign off on) the gist of the technical function of the system being proposed.
4. Development work begins. As the software is developed, there is ongoing collaboration between internal uniPHARM IT staff and developer consultants at the development level, and between project members at the project level. This process adopts some Agile concepts, with an emphasis on maintaining flexibility during development.
5. Software is alpha-tested by IT staff and beta-tested by select end users. Presentations are held if necessary.

Principles and philosophies

This section describes general principles and philosophies that drive the procedure described above.

On adopting Agile methodolgies

As an organization, uniPHARM may not be well-suited to fully adopt an Agile system for project management, primarily due to the following reasons:

• End users of the product (software) comprise a more-or-less a fixed customer base (internal staff, pharmacy staff). Thus, the product's customer needs are more predictable.
• Not involved in cutting-edge development, where technological limitations frequently force a change in project goals and outcomes.
• Not enough development to warrant learning and enforcing a specific Agile methodology.
• No dedicated project manager on staff. Many Agile methodologies require a "coach", "master", or "Product Owner".
• Small development and project teams, with all members being readily accessible. Short communication distances separate C-level and technical staff.

However, the following Agile concepts are beneficial and will be incorporated into the spirit of our custom project management strategy. Also listed is the Agile methodology(ies) to which they are most closely associated:

• Teams/roles are self-organizing / self-managing, without having to be externally assigned (Scrum)
• Maintain a Product Backlog (Scrum)
• Use of a "board" to organize and prioritize ongoing project tasks (Kanban)
• Development team is intensely collaborative (generic Agile)
• Solution-focused delivery (Disciplined agile delivery (DAD))