Abstract
In the spring of 2008, an organization was directed by the authorities to create a new section on their existing website permitting business owners to register on-une. In order to do so the organization needed to develop an on-une application where the user would enter his or her business information. As well the application would need to store data, have a search function capability as well as reporting capabilities.
A doser look on how governance, compliance and risk management (GRCM) was integrated during the project was considered. As well various elements such as
requirements, resources, lifecycle, processes, disciplines, roles, tasks, artifacts, guidelines and risks were also discussed.
The study concludes with various tables. The data in the tables indicate the level of
GRCM integration and level of capability, the RE integration and level of capability, and the Organizational Context support and level of capability. The data recorded in the
tables is a recollection 0f the author's experience working on the project as a project manager.
Key words: governance, project management committee, project steering committee, change advisory board, compliance, requirements engineering.
Introduction
An organization was legislated by the government to become a registration centre for businesses to register on-line in order to provide services to the public. The organization main focus was to ensure the businesses could register on-line before the set legislative date. The businesses needed to be registered prior to the legislative date to be recognized as a legitimate operating centre. After that date the business was known to operate
iliegaily.
The organization had various departments but the focus of this case study is on the IT
department. The IT department is responsible to maintain day to day operations as well as implementing various IT projects.
Governance Structure
The organization had a Chief Information Officer (CIO) that believed in streamiining processes, providing continuous support to its clients, proceed with innovative ideas and utilizing up to date technologies. The CIO reported project statuses as well as operation issues to the Executive Committee. Reporting directly to the CIO were the functional IT managers. The functional managers were responsible for activities within their areas.
101
Some of the functional managers were also members of project committees. For example, the Project Management Committee (PMC) was chaired by a functional managers where the CIO attended, as well as people from different departments including the IT project managers. The purpose of this committee was for the project managers to inform the
PMC of the project progress, risk, issues and dependency if any. The PMC mandate was to give guidance to the project managers, ensure the projects were on track, identify if any interdependencies existed between projects, resolve any resource allocation issues and identify any potential risks that would potentially jeopardize the projects.
Another committee that was available to the projects was the project steering committee (PSC). This committee consisted of a few IT functional managers as well as subject
matter experts (SMEs). The mandate for this committee was to give direction or make a business decision that required management authority prior to the project manager
moving forward. This committee also approved or rejected change requests (CRs) based on the Change Advisory Board (CAB) recommendation.
The CAB was another committee consisting of functional managers and SMEs in which their mandate was to assess the CR impact on the organization enterprise wide. Upon the completion of the assessment the CAB would send a recommendation to the PSC. If the recommendation was favorable the PSC would then approve the CR.
Compliance
Many of the IT projects were initiated by the business client who had specific business requirements. IT projects were also stood up to comply with new legislations. When this happened, tremendous pressure was set on the IT department. The IT department needed to ensure that the new legislation was clearly understood by the ones involved in
identifying requirements and possibly changing the business processes. Having a clear interpretation of the legislation was the utmost importance if the application was to meet legislation. There was no time for re-work once the application was built.
Requirements
The project was stood up in 2008 to satisfy imposed legislation. The business client met with the business analyst, project manager and application developer, to discuss the
following: business process changes, proposed software application, the impact on
existing infrastructure, network and systems, as well as the benefits to the organization at the enterprise level.
A business model was drawn by the business analyst representing the changes imposed by the new legislation. The model was also used as a tool to ensure stakeholders had the same understanding of the proposed business changes and were in agreement. From the business model, various case studies and scenarios were created to flush out the
requirements.
102
Process
The organization used the Requirement Engineering (RE) process to identify,
communicate and document the requirements that the system needed to satisfy. Many
working sessions were held between the client, project team members and stakeholders to capture their needs, wants and desire. Once this exercise was completed, ail the identified requirements including supplementary requirements were classified in categories,
urgency and priorities and documented with the use cases in a functional requirements document.
The working sessions were also helpful in identifying dependencies amongst other
projects being implemented and possible impact the new project may inflict to existing systems.
The functional requirements document needed to be approved by the IT department CIO, the business client, the functional manager responsible for the application built and
development and the project manager. None of the design and development of the
application work could commence, until the functional requirement document was signed by ail stakeholders. At this point the project was baselined.
Lifecycle
The organization used a combination of the waterfall lifecycle model and Unified Process to build, develop and implement the new software application. The first phase was the
inception phase where ail requirements were needed to be flushed out before going to the second phase or elaboration phase. In the first phase a business model was created, use cases were drawn up as well as scenarios which were more aligned with the Unified Process.
Disciplines
The functional requirement document was the work product for both the business
modeling and requirements discipline as per the Unified process. The next step was for the developers to analyze and design the application according to approved requirements.
Once the design was approved by the appropriate stakeholders the developers started coding in the development environment. Upon completion of the code deveiopment, the coding was then implemented and tested in the test environment prior to going into
production. The application was deployed prior to the iegislation date and the next day the business owners were able to register their business on-une.
Any changes to the project requirements or design are required to go through the
configuration management process. The change request or CR are presented and accepted at the CAB to get acceptance and then approved by the steering committee.
103