Tuesday, April 25, 2017

SDLC - Business versus IT streams

A model I created a long time ago.
 
 
 
Business responsibility
Technology responsibility
 
 























Investigation phase
·         Proposal business improvement opportunities.doc
o    Proposal for initiating a project and use of resource to improve the business; initial business benefit indication; very high level cost/benefit analysis; indication on how to continue with respect to resources, involvement of people, etc.
·         Business strategy planning.doc
·         Business change management plan.doc
 
 
[Management decision to continue]
·         Business resource planning for next phase
·         Priority definition
·         Assignment of business project manager
[Technology planning]
·         Technology resource planning
·         Priority definition
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

















 
Analysis phase
·         Business process analysis.doc
o    business process diagram’s; data flow diagrams; includes automated and non automated aspects; IT opportunities; includes as-is and to-be versions; includes interactions with automated systems
·         Vision (scope statement).doc
·         Business case.doc,
o    containing brief outline of following items: business benefit; cost/benefit analysis – business & technical / operational & project; resource requirements – business & technical x internal x external; high level indication of timelines and milestones; change management analysis
ICT Strategy planning
·         IT Strategy Analysis & Definition .doc
·         IT Enterprise architecture analysis & defintion.doc
 
[Management decision to continue]
·         Budget provisioning
·         Resource planning
 
[Management decision to continue]
·         Budget provisioning
·         Assignment of technology project manager
·         Resource planning



 









 
Business project management
·         Project plan.doc
·         Business requirements document (detailed).doc
·         Scope management plan.doc
·         Staffing management plan.doc
·         Communication management plan.doc
·         Project schedule.mpp
·         Risk management plan.doc
·         Quality management plan.doc
 
Business design and change
·         Re-organisation blue print.doc
Investigation phase
·         Exploration of technical options.doc
o    potential technical solutions; high level cost benefit analysis, including project ROI and operational ROI; optional vendor quotes; technical & functional & data visualisation in schemas and text, taking technology enterprise architecture into account
 









 
 















 
Business project management
·         Project status report.doc
·         Project status dashboard.doc
·         Meeting minutes, issue logs, etc.
·         Project change log.doc
 
Business implementation
·         User acceptance test script.doc
·         Training manual.doc
ICT project management
·         Project plan.doc
·         Scope management plan.doc
·         Staffing management plan.doc
·         Communication management plan.doc
·         Project schedule.mpp
·         Risk management plan.doc
·         Quality management plan.doc
 
System analysis & design
·         Business requirements (system requirements).doc
·         Information analysis.doc
·         Functional design.doc
·         Technical solution design (system architecture).doc
·         COTS evaluation.doc











 
ICT Project management
·         Project status report.doc
·         Project status dashboard.doc
·         Meeting minutes, issue logs, etc.
·         Change requests.doc
·         Project change log.doc
·         UAT sign-off.doc
 
System development
·         User acceptance test script.doc
·         User manual.doc
·         Technology operation manual.doc2







 
 
 
[Management decision]
·         Sign off
[Management decision]
·         ICT operations acceptance
 
 
 
 
 

Thursday, February 23, 2017

Be careful with assigning more power to the CSO to improve information security

Information security has never been as important as now. It's being said and heard everywhere. But organisations should be cautious to translate this to more power for the CSO/CISO.

Information security is a complex matter and is all about risk management. Risks should be assessed daily throughout all levels of the organisations: business management, IT management, IT specialists and end-users. When a firewall expert makes decisions on how to configure a firewall, it is impossible for a Security Officer to participate. The same applies to when the business owner of an application specifies his requirements.

To make these security decisions, you take a variety of issues into consideration such as the perceived threat, the cost to mitigate, impact on usability or operational efficiency.

Information security is just one of the subjects that is being delegated down through the management hierarchy, just like for example financial responsibility.

The risk is that if a CSO and his team are assigned power, they will start telling the people in the organisation what they can and can’t do. And they will threaten staff with non-compliance and force them to follow rigid frameworks. Those others than might take a passive approach and will not take their responsibility and refer to the security department for taking actions. The relationship between Security Officers and the IT-team is in many organisations far from optimal. This has a negative impact on the actual security, even if you are compliant. Compliance does not mean that all is secure.

Specifically, because information security is so important, all employees and all managers should be made fully aware of their responsibility. They should be trained and should be guided with the process. Their effectiveness should be measured through personal KPI’s and team KPI’s. Audits will assist to measure the effectiveness of the organisation but audits and compliance should still be considered as a tool to assist with the objective of the organisation. And information security is only one of the objectives.

The Security Officers play of course a very important role. They can’t be made responsible for the security of the systems. Simply, because to achieve good security, actions should be taken spread out through the organisation that requires too much knowledge of too many technologies.

The Security Officers therefore should use the regulations and frameworks to guide the organisation through the processes, help them to check the status where they are at and provide recommendations for improvement. Of course, when they see a risk, they should not give in and still report the risk via an escalation path to management. But management then decides whether to accept the risk or to act.

If you need to improve your information security, I recommend to set stricter KPI’s for your managers and transform Security Officers into friendly but honest consultants.













Thursday, December 29, 2016

Resource planning


Resource planning is an essential aspect to doing projects. You need to do this however for a large part outside de project context or outside the control of the project management office. It will need to be done by the (operational) IT managers. I thought to write this down as I see too often that organisations still struggle with this. Though it will never be a stroll in the prak.

Projects come and go and are generally resourced partly through people from the existing operational teams and partly through temporary hiring. Projects are these days less about completely building something new and more about adding or changing something that already exists. Therefore it is important to use existing skills and knowledge.

Certain resources will work almost fully dedicated for the project for a longer period of time. Other resources will need to perform tasks intermittently and for shorter durations. Planning the latter group is the most difficult. Those people will work probably for many projects and will also have to perform operational support tasks.

Because the IT manager will know which person has the right skills to perform the required project tasks, it is the IT manager who will need to do the resource assignment. In fact, the IT manager has the responsibility to maintain the full resource planning for everyone within his team. Additionally, it is advised that project resources are also recruited and managed by the IT manager. In that case, he can assign some support staff to work on the project so existing knowledge can be leveraged for the project and some of the temporary staff can do support work.

With respect to resource planning, the IT manager will first of all need to make an estimate of the total amount of operational support work he has that needs to be performed. These tasks can be work related to:
  • Operational support tasks such as incident and problem management, fulfilling user requests, responding to system events, systems monitoring, service desk tasks, applying software patches, replacing faulty, etc.
  • Proactive support tasks such as upgrading software to a new versions, structural hardware replacement or implementing changes as requested by the users (all these activities could potentially be executed as projects).
  • Overhead tasks such as team meetings, training, holidays, sick days, etc.
This gives a baseline of the amount of resources that is minimally required. Certain tasks will require to be performed by people with specific skills. In those cases you will need to plan on an individual basis.


It is not always required to plan on the individual basis and you could maintain the information on the summary level.


The “ total available” gives insight in how much time is available for projects. If projects require more, you will need to insource additional people. If these resources work only for projects, then you could leave those people out of your operational resource planning and leave the management up the project manager or the project management office.

As you will perform multiple projects and will have multiple project managers, you will also have some project coordination through a project management office or something similar. 

When planning all your projects, you will need to ask yourself the question whether you will be able to perform all those projects. It happens unfortunately too often that certain resources are over-allocated by different projects because there was not overarching planning. Each project will have to make its own resource plan and the project management office will need to integrate those plans to see what the total project resource demand is per operational team or some cases per individual.

You will get a resource plan similar as you would have per team but instead of tasks you would haven projects. Each project manager will provide a single line item per resource or skill/team for the resource plan. You can then reorganise this demand to a demand per team. On a summary level, the total demand from all projects could be something like the table below.


If you then subtract the demand for a team from the availability, you see what is required for additional hiring of staff. Using the above examples, this is for team 1 as follows:


In this example, you will need an additional person with specific skills. Initially for 2 days per week, then for 1 day per week, then not at all and then you need this person again. That is unpractical. Usually you just can’t hire skilled people this way. Therefore you might need to adjust your project portfolio by either delaying or cancelling a project. Another option is to delay or cancel certain operational tasks.

Adjustments will need to be made continuously. You might need a Unix administrator only for 2 days at the end of the project. You will need to plan this into the resource planning but as we all know, projects run rarely according to the plan. You might even find out only a week before that you need to reschedule. Alignment between projects and the support tasks is needed. If you, as an IT manager, have been strict enough not to give away the time required for support tasks and have planned sufficient contingency into this, you will be flexible to accommodate these last minute changes. Instead of doing the support tasks next week, you do them this week. This flexibility can be obtained for a large part from the proactive tasks and less from tasks such as incident management.

What you definitely should not do is to ignore the issue and simply over-allocate the resources. What happens then is that support tasks are delayed or cancelled which over time will result in an increase in the number of incidents. What also will happen is that projects will take longer than planned and will be delivered with a lower quality. The latter will result in a higher number of incidents for the support teams to resolve.

Besides people, resource planning can also apply to the systems themselves. If you have 3 projects that all want to modify an existing component, all through the development, testing and production-deployment phases, you will need to align all these activities between the projects and support activities.