Study notes on Cobit: Managing projects

Scope, cost and schedule

Suppose that you're the software development manager of a publishing company. To create a new market, the company is considering developing a self-publishing platform for authors to publish their works (initiating a project).To help the CEO to decide to go ahead or not, you have gathered the rough requirements (deliverables) and estimated a rough cost (e.g., MOP1,000,000) and schedule (1 year). So, the CEO decided to go ahead and you have been assigned as the project manager for the project. Your mission is to ensure that the deliverables (scope) are delivered within the allocated cost and schedule (the three most important constraints for a project). This is called project management.

Good planning

Is this mission possible? You must make sure that for the given scope, the cost and schedule are reasonable. At the initiation phase, your estimate may be quite rough because there were no detailed requirements yet (so, you should add a large buffer to it, whose size depends on the level of details available). Now, you need to identify all the requirements in details and get a better estimate on the cost and schedule.
How? You could adopt a divide and conquer approach. First, you can break down the project into:

1. A short upfront analysis to identify the features (which you will use to estimate the cost & duration): 3 days (according to previous experience)


2. Development: ???


3. System testing: ???

For each part, you can further divide it. For example, for the development part, you can break it down into the deliverables (features):

1. Analysis


2. Development
   
   
   
   1. Author management
      
      
      
      1. Register account: 2 days (given the previous experience of the same development team)
      
      
      2. Edit profile: 1 day
      
      
      3. ...
      
      
      
      
   
   
   2. Publication management
      
      
      
      1. Create a publication: ...
      
      
      2. Push a publication to Amazon: ...
      
      
      3. ...
      
      
      
      
   
   
   
   


3. System testing: ??? (you can estimate it by the number of features, the number of tests, etc.)

You can the cost of each small item similarly. The total cost is just the sum of all item costs. For the schedule, basically you can assume that the analysis, development and system testing will be in sequence, so you can determine their individual schedules (not really 100% true, as system testing could be done before everything is implemented). For the features in development, basically they can be implemented in any order you want. As not all programmers will be working on the same feature, they won't be done in sequence, but it is fare to plan what features will be done in a particular month or week.
Note that with this approach you can plan not only the cost and the schedule, but also other resources needed (e.g., programmers, testers, business analyst, 3rd party software components and tools, hardware) and when.

Uncertainties, changes, monitoring and control

After creating the project plan above, can you just assign people to the tasks and come back again in one year to receive the working system? No. There are way too many uncertainties and changes in a typical project that will throw your project off the track. For example:

• What if the progress of the development team is slower than planned? (planning risk)


• What if a programmer quits in the middle of the project? (human risk)


• What if the framework adopted for the project doesn't work as well as expected? (technology risk)


• What if the new programmer is not getting along with another programmer? (human risk)


• What if the testers aren't working well with the programmers? (human risk)


• What if the testing hardware is delayed by the supplier? (supplier risk)


• What if the CEO wants to add some new features? (scope change)


• What if the CEO wants to release the system two months earlier? (schedule change)

Therefore, you (the project manager) must monitor for any potential and actual problems and any deviations from the plan and take actions to correct the problems or deal with changes (control the project). Therefore, in accordance with the project management framework or methodology adopted by your company, you should have phases in the project as inspection and approval points. The phases can be time-based such as monthly or weekly meeting (as in XP or SCRUM) or based on deliverables (e.g., when the author management sub-system is implemented).

Quality as the 4th major constraint

Suppose that the progress of the development team is slower than planned or the CEO wants to add some new features, what would you do? Unfortunately, instead of really fixing the problems by speeding up the team or removing unnecessary features, many project managers will choose to cut the quality by overloading the programmers and decreasing the testing (unit testing embedded in the development, the system testing, etc.). The result is that, the features seem to work, but only in some occasions and will behave incorrectly in others.
Why is quality often the first to get cut? It is because quality is not as visible as the other constraints: scope, cost and schedule. Any deviation in these three can be found easily, but it takes very closed interactions to discover quality deviations. In addition, the longer the problems are covered (e.g., after being deployed), the more money it will cost (e.g., service interruptions, loss of businesses, lots of service calls, training for workarounds, redeployment for the fixes).
Therefore, quality is not an option. It should be considered the 4th top constraints in project management. As mentioned earlier, you should plan, monitor and control for quality in your project (that's why you have all kinds of testing and validation in the project).

Keeping the sponsor happy to fuel the project

What if you only report to the project sponsor (here, the CEO) and other stakeholders in a year? They will lose enthusiasm by then. So, to keep their enthusiasm and more important their commitment and support for the project (that's how to ensure the resources for your project), you should report the project status, deliverables so far and etc. to them regularly. This is like fueling your car regularly on a journey.
Also, after the project is ended (closing), you should provide a final report to the project sponsor and other stakeholders mainly to show that you have delivered the required deliverables in high quality, within cost and schedule. Again, this is to make the project sponsor happy about the project and you for his future support.

Getting long lasting benefits out of the project

Basically, after the project is closed, all you enjoy is the deliverables. However, there is more you can get out of the project. For example, if you have found a best practice with working with that framework or working with a particular stakeholder, you should document it for future use.

Coordination between projects

In addition to the self-publishing platform, your company has other projects supporting the same strategy of enabling authors to self-publish. For example, it has a market research project to identify the needs, a promotion project to promote the service, and etc. Obviously, the projects must be coordinated. For example, it is impossible for you to get the detailed requirements before the market research project identifies them.
Therefore, there needs to be a program manager (e.g., a vice president) to do that (managing the program which consists of the interrelated projects). In addition, the company should adopt a program management framework to ensure proper organization (e.g., a program management committee consisting of the program manager and all the project managers) and processes are in place to support the prioritization and coordination of the projects.

Adopting and tailoring a project management framework

You've seen the key control objectives above for project management. Cobit recommends that your company adopt a project management framework (e.g., based on PMP body of knowledge or PRINCE2) covering the above, with customizations based on project size, risk, complexity and etc.

Study notes on Cobit: Assessing and managing IT risks

Life could be at stake

Suppose that you were the CIO of a hospital. To allow the people to quickly locate expensive medical equipment, you had implemented a WiFi tag tracking system and it had been working fine. Until one day, a patient was rushed to the ICU for urgent operation and the surgery doctor was looking for a certain piece of critical but rarely used equipment but it just couldn't be found. As a result, the patient died and the hospital was sued and ordered to pay a million dollars for the damage. The incident was also widely reported in the media. Investigation showed that the WiFi tag on that piece of equipment simply ran out of battery, but the hospital didn't have a procedure for checking for low-battery WiFi tags, so it was considered a negligence.
The above example shows a risk (medical equipment not found when it is urgently needed) that has become true. It had a very serious impact (loss of human life, public image of the hospital, financial damage). So, the question is, how to mitigate the risks?

Identifying and assessing the risks

The most important thing is to identify (find out) the risks first, otherwise you won't even consider them at all. How to identify the risks? As risks are not just about IT, your organization should appoint someone higher up to take overall accountability for risk management in the company. This role could be the chief risk officer. He should form an enterprise risk management committee and the members should include himself, the CIO (or someone in IT responsible for IT risks), compliance officer (for legal risks), and probably other business executives. Then, the members will work together to identify the risks. This should take the form of a brainstorm session or some other forms.
As there are so many possible risks to consider (the Earth hit by a meteor from the outer space?), it is ineffective to list them all. Instead, you should focus on those applicable to your organization's activities and environments (treating patients, laws for hospitals, local labor laws, in earthquake zone? etc.). This is called establishing the risk contexts. Then, you should focus on those risks with a high impact and/or a high probability (so, you're assessing the impacts and probabilities of the risks at the same time). For example:

1. High impact and high probability such as a baby is stolen (assuming you have very poor security) or a patient dies due to wrong dose of medication (assuming your staff are very lousy). Usually this kind of risks should not exist for very long as the company would have gone out of business.


2. High impact and medium probability such as the WiFi tag case above.


3. High impact and low probability such as avian flu pandemic.


4. Medium impact and a high probability such as hardware failure of a server.

Note that there is no strict definition of what is a high impact (MOP10,000 high impact or just medium impact?) and what is high probability (once a month or once a year?); it all depends on the rough concepts across the risk management committee members.
In addition, it is usually very difficult to quantify the impact to a dollar amount (how much a human life is worth in dollars?) or to quantify the probability to a number (the chances of having avian flu pandemic in this year is 0.1%?). So, in most cases you will just roughly classify them as high, medium or low.

Mitigating the risks

Once you have the list of risks (called the risk register), the risk management committee can prioritize them (by their impact and probability) and consider how to deal with each of them. How? It is simple: either reduce the probability or reduce the impact. For example:

• For the risk of babies being stolen due to poor security, just enhance the security to reduce the probability of losing a baby. Put security guards at various spots in the hospital (in particular, the baby room). Attach WiFi or RFID tags to the babies for checking whenever they are transported.


• For the risk of WiFi tags running out of battery, locate all the the equipment everyday to detect low-battery and replace the battery as required. This reduces the probability of running out of battery when the equipment is needed.


• For the risk of avian flu pandemic, while you can't reduce the probability, you can reduce the impact. For example, set up remote interaction system between the hospital and n quarantined facility for avian flu patients that supports remote diagnosis and automated delivery of medication, so that the medical staff staff members don't need to physically enter that facility and won't get infected.


• For the risk of a server hardware failure, you can reduce the impact by having a stand-by server, a 2-hour emergency repair service contract, a pool of spare parts and etc.

As you can see above, to mitigate the risks you may need to change your procedures (e.g., locating all the equipment everyday), IT infrastructure (stand-by server), contracts (emergency repair), to integrate risk management into all elements of your enterprise.

Transferring the risks

Sometimes it is just impossible or too difficult to reduce the probability or the impact of a risk in isolation. For example, a patient dies due to a mistake by the doctor. In that case, you can buy insurance. So, you will pay a certain small amount (a small impact but 100% probability). Essentially, you are trading a risk with a high impact (could be millions) and a low probability for a risk with a small impact and a high probability with the insurance company. For a smaller organization with limited cash such as your hospital, the latter is easier to absorb. For a larger organization with a lot of cash such as the insurance company, the former is more profitable.
In addition to insuring, outsourcing is another way to trade the risk: you just pay someone else to do the risky task for you. You pay more but the outsourcer takes the risk.
In either case, the event now has a 100% probability so in common sense is no longer a risk as it will definitely happen. Therefore, you may view it as transferring the risk to the insurance company or the outsourcer by paying them.

Monitoring and reviewing the risks

So, you have taken some measures to mitigate the risks, but do they work? Therefore, you should review regularly to see if the measures are indeed effective enough to reduce the probability or the impact enough. If yes, fine. If no, you need to come up with more mitigation measures. To allow for such reviews, you should record the corresponding mitigation measures for each risk in the risk register.
Will a certain existing or new risk become more prominent? For example, are there indications that an avian flu pandemic is coming? A new law is coming into effect? To deal with these cases, the risk management committee should review and update the risk registry regularly accordingly.

Study notes on Cobit: Managing quality

What is quality?

Are your users happy with, say, your email service? This is what quality is all about. If the email system is so slow or fails to catch spam effectively, the users may be unhappy about it. If you (the CIO) don't know about it and thus aren't doing anything to address the problem, they (probably including the CEO) will lose trust in you and you will have difficulty getting budget for existing or new initiatives. So, getting the users happy about your services (quality) is critical for your career as the CIO.

How to ensure quality?

Take the email service as an example, it is basically an automated service so the quality mainly depends on the email software and the infrastructure (server and network) instead of human being. How to ensure the quality of, e.g., the email software? You may follow such a process:

1. The CIO, the business analyst and the solution architect discuss with the representative users and other stakeholders on the requirements. For example, you may determine that it needs to support shared and personal address book, anti-spam, anti-virus, web access from anywhere, digital signature, company wide archiving (for legal purpose). There are also non-functional requirements such as: it shouldn't take more than 1 minute to process and deliver an incoming mail (performance), all client communication must be secure (security), the service should be available 99.9% of the time (availability), etc.


2. The architect evaluates the email packages on the market to identity those that support the above requirements.


3. The architect selects the one that meets the requirements, at a lower cost with a lower risk.


4. The architect requests the representative users, in your actual environment with a heavy work load.


5. The CIO finalizes on the decision with all the stakeholders.


6. Deploy the solution.


7. Get user feedback.


8. Get user feedback regularly to see if the service gets deteriorated (e.g., is it getting slow due to increased volume of emails?) or there are new requirements (e.g., shared calendar?).

If you check carefully, you will note that this process is actually applicable to most types of solution acquisitions and has little with the specifics of email service. The process is basically:

1. Get requirements (control point for quality).


2. Evaluate & test possible solutions (control point for quality).


3. Select a solution.


4. Validate the solution (control point for quality).


5. Finalize & deploy on the solution.


6. Validate the solution again in production (control point for quality).


7. Monitor the quality regularly and improve as needed (control point for quality).

That is, to ensure quality, all solution acquisitions should adopt this process. Adopting such a process with quality control points is the basis of quality management. Of course, you also need people capable of doing this type of work (in this case, the business analyst and the architect).

Ensuring quality throughout the whole enterprise

The above process deals with the quality of acquired solutions, but what about others such as development of applications, support services and maybe other non-IT products or services? To ensure that everything is covered, there should be someone higher up such as the quality director who is in overall charge of quality (in ISO 9000, this is called the management representative). He should somehow ensure that the processes for the company to develop its products or to deliver its services (including those for internal use which is typically the case for IT) have incorporated control points for quality.
As this is a lot of work and much of the work requires professional knowledge (e.g., it's difficult for a non-IT person to ensure quality in software development), the quality management representative should ignite the care for quality in the minds of all staff members, so that they drive the development of the processes to ensure quality instead of them being driven by the processes.

Summary

As you can see, to ensure quality, your company needs the organization (quality management representative and all other people actively working to ensure quality and their relationships) and the processes in place designed to ensure quality. These two are the main elements of a quality management system (QMS).

Study notes on Cobit: Managing IT human resources

It is the people who will make or break the IT capability

Suppose that you have in place the best IT processes in the world and all the resources you want, but what if:

• Your programmers are always blamed by their manager for any faults found in the software while he takes all the credit (motivation issue)?


• Your system administrators don't care about security and use simple passwords (attitude issue)?


• Your business analysts can't communicate with the users smoothly and pushing the users away (skill issue)?


• Your support personnel are not familiar with the services being provided (skill issue)?


• Your architect was actually hired by a competitor to steal your business secrets (law and ethic issue)?

Then there is no way for you to deliver business values through IT. Therefore, after all it is the people who will make or break your IT capability. Therefore, it is critical that you ensure your people:

• tend to comply by the laws and ethics.


• have the required skills.


• have the required attitudes.


• are motivated.

How? These items are of different natures so you need to treat them differently.

People tending to comply by laws and ethics

Most people do try their best to comply by laws and ethics. To ensure that it is indeed the case (in particular, if you're in a sensitive business such as department of defense or drug research company), you can perform a background check, like:

• check if the candidate has a criminal record.


• check with his previous company to see why he left or why he was fired.


• check his public records such as blogs, Facebook, forum postings for any tendency for illegal activities.

People with the right skills

There are many skills in IT that can come and go easily (e.g., Netware administration). So, instead of hiring a person who has such a particular skill, you may look for someone with the ability to learn, by self-study or training, then create a training plan for him and other employees on an annual basis to meet the then current demands.
However, there are some fundamental skills that is very hard to acquire. For example, the skill to write readable code, the skill to diagnose a problem, the skill to search for answers, the skill to understand others, the skill to think strategically, the skill to think out of the box and etc. If such skills are important to you, you should hire the people with such skills.
How to test if the candidate possesses such skills? Usually I will just give him some practical tests. For example, to see if he can search for answers, ask him some questions and tell to him search for answers and see how good he is.

People with the right attitudes

Attitude is very much like the fundamental skills above. It is difficult to change a person's attitudes:

• Pessimistic vs optimistic


• Risk-aversive vs risk taking


• Blaming others vs responsibility taking


• Improvising vs planned


• Self-centered vs empathic


• Following vs leading


• Negative vs positive


• ...

Therefore, you should hire the people with the desired attitudes. How to test if the candidate possesses such attitudes? Usually I will ask him for his past actions. For example, to see if he has the leading attitude, ask him if he has taken any initiative to lead people to solve a problem.

Motivating people

Motivation is not something you do when hiring. It is what you do everyday. This is like fueling your engine constantly. How to motivate people?
First of all, money or other extrinsic rewards don't really motivate people. Why not? For example, let's say you got a pay raise of MOP2,000, you would be motivated and work harder, right? What if you found that all the other colleagues got a pay raise of MOP4,000? Then you would be demotivated even though you had more money. It means what you really care is the recognition of your value, not the money you receive.
From my experiences the following simple actions do motivate people:

• Trust (autonomy). Trust your staff members and let them decide how to achieve the targets you set. Do not micromanage.


• Praise (recognize). Praise them for the good things they have done.


• Help. Help them remove the obstacles they face. Help them become better to avoid any similar bad things from happening.

Study notes on Cobit: Communicating management aims and direction

Defining or maintaining IT policies, standards and procedures

Suppose that there has been a user in your company who lost many important files because the hard disk of his computer died. Obviously, he didn't save his files into the network drive. To prevent similar incidents again in the future, the chief information security officer proposed to make an addition (bold below) to the IT standard, which belongs to a certain IT policy and is shown below.
IT policy 10: All employees should take care of the information they created against possible failures.
IT standard 123: File handling

1. All user files created must be saved to the network drive instead of the local hard disk.


2. If some files (at the confidential level or above) must be put onto a portable device such as a USB disk (to acquire a USB disk, refer to procedure 456), the file must be password protected (refer to the technical procedure 789).


3. ...

Procedure 456: Applying for USB disks

1. Fill in the form xyz.


2. Get the approval from the department manager.


3. Get the USB disk from the service desk.


4. Return the USB disk by the deadline stated on the form.


5. ...

Technical procedure 789: How to encrypt files

1. ...


2. ...


3. ...

After defining or amending the policies, standards and procedures, depending on the authority of the chief information security officer, he may seek approval for this change (from the CIO or the chief risk officer of the company). But it is far from done yet, as the people will not automatically follow them.

Rolling out the IT policies, standards and procedures

So, he will need to inform all the people relevant (all users in this case) of the changes and the rationale behind it (if they don't understand the rationale, they will have no motivation to adhere to it). How?

• Emailing them is a quick way but many people will simply ignore it. You may insist to get a reply and chase those who don't reply. But later people may simply reply to you without reading the mail.


• You may conduct a briefing but it is very time consuming, in particular, for such a small change or if there are multiple locations in your company.


• You may record a video to talk about the change and email them the link.


• You may seek the help of the department managers to disperse this information.


• Any other ways that you think is the most effective.

The above is for existing employees. What about new employees? Make sure the policies, standards and procedures are included in the orientation.

Compliance

As you can imagine, it is difficult to get all people to understand the change, not to mention to really act according to it. So, it is almost always necessary to check if they're really doing it. That is, go to some users' PCs to check if there are any files saved locally (to save time, check against other terms in the IT standard or other standards). Of course, to perform such audits, you must get management approval first and inform the people in advance that audits will be conducted.

Study notes on Cobit: Managing IT investment

Forecasting (planning) the business values and costs

Suppose that you're the CIO of a movie rental store chain with 10 stores at different locations. The CEO has selected your proposed IT strategy of implementing an enterprise wide collaboration system (e.g., Sharepoint or Alfresco) to enable document sharing and project management, using a SaaS solution. As discussed before, you (the CIO) have forecast (planned) the business values and costs as below.
Values:

• Allow all the users to access the same documents even though they are on different sites. The information to be shared includes updated price list, current promotion programs, company policies, procedures and guidelines, document templates, best practices, staff phone number extension list.


• Allow different project team members to see and update project tasks. Allow project managers to see the overall status of the projects.

Costs:

• Subscription fee to the SaaS solution: MOP100 per user per year. There are totally 30 users, so the annual cost is MOP3,000.


• Internet access: the company already has Internet access for all the sites. It is estimated that it will not require upgrading the bandwidth. If the Internet cost is significant, you may estimate the percentage that will be used for this service so that you can justify the Internet access. In this example, let's ignore it.


• Service desk support: your service desk will provide support to the users. However, it is difficult to estimate how much of the service desk will be used for this service. But if you'd like to justify the value of existence of your service desk, you may need to estimate or measure it, to link the cost to the business value. In this example, let's ignore it.


• PC clients: the existing PC clients can handle it easily as almost everything happens in the browser.


• Testing by IT: it is estimated that an IT architect and the QA manager will spend 1 week to test the solution. Assuming that their hourly rate is MOP200, this will cost 2*5*8*200=MOP16,000.


• PC client configuration: you will need to add a bookmark to the browser and a shared folder (to hold the document templates) for each user. This is not a good way, but let's suppose that you lack an automated solution. Let's say it will take 2 hours to visit and configure the PCs on each site, so it will take 2*10=20 hours. Assuming that the hourly rate of a technician is MOP100, this will cost MOP2,000.


• User training: you will conduct two user training sessions at the headquarter. It takes 1 day (8 hours) for preparation and for each session 2 hours for delivery. It will also take each user 1 hour to travel to the headquarter and 2 hours to attend the session. Assuming that the hourly rate of the trainer is MOP200 and that of the user is MOP50, this will cost (8+2*2)*200+30*(1+2)*50=MOP6,900.

So, the CEO has accepted this IT strategy and approved the budget (once-off: MOP24,900. MOP3,000 annual).

Tracking the costs

So, some time later you start to implement the project. In the process, you should keep track of the costs to make sure they don't exceed the budget. For example, if the testing of the architect and the QA manager shows that the existing Internet bandwidth must be upgraded from the existing 256Mbps to 512Mbps for headquarter (due to the need to perform lots of uploads), this will cost an extra MOP300 per month.
When seeing this deviation, what should you do? There are a couple of options like:

• Try to reduce the cost. For example, check if the bandwidth of the headquarter is being used wisely (e.g., many staff members watching unrelated videos on Youtube?). If so, cut those wastes.


• Report to the CEO and other stakeholders about this bad news. They may decide to go ahead, to abort the project or to even suggest some other solutions for you.


• Keep it secret. This is not really an option and you will pay dearly later! So, don't do that.

Tracking the business values

In addition to tracking the costs, you should also keep track of the business values to show to the CEO and other stakeholders. For example, after implementing the project, the users should start using it. But how to show or measure the business values? Usually it is very difficult to quantify the business values into money amounts. In fact, it is also very difficult to measure, qualify or describe business values. Here are some possible ways to "measure" the business values for this example:

• show that the updated price list has indeed been put into the system and how frequently it has been accessed.


• show the comments from the users regarding how much better they feel when getting the updated price list this way instead of the old way (e.g., fax).


• show the comments from project managers regarding how much better they feel when managing projects with this system.


• so on.

What happens when there are deviations? For example, if after implementing the system, nobody accesses the updated price list in the system? Then obviously you're in big trouble! Try to find out why they aren't using it. For example, if the guy in the headquarter is uploading the price list in a timely fashion, talk to him to find out why and try to resolve the problem.

Quantifying business values

In the official Cobit document, it is recommended that we quantify business values into amount of dollars and then prioritize or select IT strategies based on monetary comparison (e.g., ROI, net present value, payback period). While this may sound scientific, I seriously doubt its practical usefulness. For example, how to measure the value of easier project management by having a global and updated view? It really depends on the nature of the projects being managed, the people using the system and even the current business environment, etc.