Please login or join to subscribe to this thread
I can not give you templates but I will try to put here as far as I can about the actual process followed in my actual work place which I was accountable to define. Our governance process is tied to SOX controls on project. We use a stage gate life cycle which is on top of every life cycle model/process we use and the approach we use. Basically we have the following stateges: 1-feasibility and approval to check if the business case was approved. 2-business blueprint to check if requirements (product and project) were agreed and approved. 3-realization design to check if the solution design was agreed and approved. 4-realization test to check if user acceptance test was agreed and performed with no open incidents. 5-final preparation to check if all is ready to proceed to move the solution to production environments. 5-project close to check if everything needed has been completed and agreed after hypercare.
Look at oceg.org
Is the purpose of this project to define and implement controls to be in compliance across the different business units?
The types of deliverables you might have in that case would be policies (defining the expectations), control objectives (translating the policies into specific expectations), training/guidance/support for project/operational teams on meeting the control objectives, and audit/assessment procedures and staffing to monitor compliance with the objectives.
However, as far as how to get started, this is the same as for any other project - identify stakeholders, get a charter formally approved, and start the process of understanding scope and formulating your plans.
"Is the purpose of this project to define and implement controls to be in compliance across the different business units?"
Yes, you interterpret it right.
Across the BUs and across the globe, that's actually 'the challenge'.
Though other global BUs comes under the same bigger umbrella as one organization, but fundamentally they are vastly different - can be safely assumed as group of 'individual organizations'.
The 2 reasons why I emphasied on 'individual' word are:
1. Some global units are not 'major' development centers, and this has an impact on the willingness to impose those Software centric policies in their org.
2. Buyout would be needed from all the heads/ CEOs of these units-cum-org as they have to approve formation of the whole framework.
I will go through it. It looks massive. I am quite hopeful to get some breakthrough with this.
However, that is where a lightweight, minimally sufficient policy combined with a principles and control objectives-based framework will serve you much better than a process-heavy approach which will inevitably become "one size fits all".
If each BU buys into the policy, principles and control objectives, it then becomes their responsibility and that of their control officers to define and monitor "how" those are implemented.
Please login or join to reply