The Level of Math in Risk Management March 28, 2015Posted by Edwin Ritter in Project Management.
Tags: decision matrix, decision process, decision theory, known unknown, risk, risk management, uncertainty, unknown unknown
add a comment
Managing risk and selecting the best mitigation choice can be hard. There are many factors that will influence what choice is selected. Using data to manage risks and assess choices is always good. Having a process to use that data to evaluate choices is better. Having good data to assess risks and a process to determine choices is the point of this post.
Some background first. Decision theory is a complicated subject and is used in many different fields in business and leisure (i.e. – games). There are 4 basic elements in decision theory: acts, events, outcomes, and payoffs. A formal definition is “the mathematical study of strategies for optimal decision-making between options involving different risks or expectations of gain or loss depending on the outcome.” An informal definition of decision theory could be “identifying the values, uncertainties and other issues relevant in a given decision, its rationality, and the resulting optimal decision.”
Got that? Good. Sorting out between what is known and unknown can assist in which risk mitigation choice is best. It is always preferable to be in the magic quadrant and deal with knowns rather than unknowns. Consider these groups in a matrix:
- Known Known – circumstances or outcomes that are known to be possible, it is known that they will be realized with some probability.
- Known Unknown – circumstances or outcomes that are known to be possible, but it is unknown whether or not they will be realized. This is known as a Risk.
- Unknown Known – circumstances or outcome a modeler intentionally refuse to acknowledge that he/she knows.
- Unknown Unknown – circumstances or outcomes that were not conceived of by an observer at a given point in time. This is known as an uncertainty.
In short, those things we know we don’t know are risks and those things we don’t know what we don’t know are uncertainties. In the magic quadrant, both are below the line.
Still with me? The uncertainties, the unknown unknowns, are the hardest pieces to deal with. With decision theory, assigning values of probabilities helps determine which choice is best. As an example, consider the following image. Getting the data to assign the options and organizing into a concise arrangement is where the math comes in.
Not all risks require this level of math and analysis to determine the best mitigation choice. The level of math should be appropriate to the complexity of the project and the potential risks involved. It is worth noting that the difference between an issue and a risk is :
– an issue is something that has occurred which impacts* the project.
– a risk is something that may or may not occur that can impact the project.
* impact can be positive or negative.
I prefer to stay above the line and deal with knowns and those risks that are relatively small on my projects. It makes for simple math and for projects where my preferences matter, I find those are the best projects to manage.
Glad I did not lose you and you got this far. How do you manage risks? What is the level of math required for risks? Simple? Complex? Hybrid? Comments invited.
Cloud Life in 2015 February 27, 2015Posted by Edwin Ritter in Cloud Computing.
Tags: cloud, cloud computing
add a comment
Are we there, yet? Seems everyone is talking about cloud services these days but not everyone has migrated. Once you and your team have configured the repositories, gotten used to the tools and established new or revised processes, life is good. The migration can vary of course from easy to arduous. One thing that seems to get glossed over is moving things from here to there. Things like project assets (images, videos, content – you know, stuff), documentation, spreadsheets. I know, I know – it’s very easy. Drag and drop. It is easy, to a point.
While there is a lot of talk about cloud services, it seems to me we are in the early stages of life in the clouds. We are still using desktop based tools, not cloud based widgets. I imagine a day when setting up repositories will be done for groups of files and directories using objects. Content management via metadata and aligned with a specific taxonomy. What’s that? It exists already? Yes, it does in certain places but it is not ubiquitous and not homogenous (yet). Too often, we are dealing with unique files, not a larger data set.
In the interim, it’s about the journey not the destination and keeping the business running while you migrate. Tools change all the time and there will be a day when migrating/updating/changing repositories will be done at a higher level than it is today.
And, hey, you – get off of my cloud.
Virtual Work January 30, 2015Posted by Edwin Ritter in career, Cloud Computing.
Tags: life-work balance, remote work, virtual office, virtual work
add a comment
While in the office, how many times have you heard someone ask the old saw ‘Are you Working hard or hardly working?’ Funny when used at the right moment and a proven gambit to spark friendly banter among co-workers. In the digital age that is reflective of current work practices, a variation to the phrase could be ‘Are you working virtual or virtually working?’
The difference is more subtle than you might think. Working virtual can mean working remotely. That is, you may not be in the office for a short time but will be back physically. The expectation of management is that while remotely working (wherever that may be), you will be working on the same tasks as when in the office. Virtual work is conceptually similar but different in that you are never physically in an office with co-workers. No office cubicle, no ad hoc hallway or water cooler conversations, no in person meetings or face time.
There are definite advantages to virtual jobs. Top of mind advantages include:
- life-work balance,
- minimal commute time and
- flexible work hours.
Having a virtual job is not for everyone and certainly not possible with all jobs. It does take different habits with virtual work. Making the transition to working in a virtual office also requires a change in mind set. Being comfortable with having lots of alone time is part of the transition. The interactions with co-workers is reduced and takes a bit more effort (and, time) to pose a question, have ad hoc conversations via chat or email.
In response to the question, I am virtually working and enjoy what I am doing.
2014 Ruminations in review December 29, 2014Posted by Edwin Ritter in Trends.
Tags: annual report, Ruminations
add a comment
The WordPress.com stats helper monkeys prepared a 2014 annual report for Ritter’s Ruminations and Ramblings blog. Here is the year in review.
Here’s an excerpt:
A San Francisco cable car holds 60 people. This blog was viewed about 2,600 times in 2014. If it were a cable car, it would take about 43 trips to carry that many people.
Ruminations of the 2014 Season December 24, 2014Posted by Edwin Ritter in Grab Bag.
Tags: Christmas 2014, holiday, holiday spirit, joyous holiday season, the holiday season
add a comment
It’s the holiday season and I, like everyone, am busy with year end events. I want to wish everyone a happy and joyous holiday season. We have much to be thankful for and the future looks bright with the promise of both things known and unknown.
May we continue to stay connected and enjoy each others’ company, whether in real time or virtual. Cheers and happy holidays. See you in 2015!
Keep getting Smarter November 28, 2014Posted by Edwin Ritter in Grab Bag.
Tags: closed loop, closed loop approach, communications, decision process, feedback, posterior probability, probability
add a comment
A fundamental challenge in every job is communications. Getting your audience in sync with your message is fundamental to communicating effectively. In previous posts, I have talked about using a closed loop approach, the value in feedback and how numbers improve decision making.
Segue to how the concept of feedback or closed loop is used with mathematics. Specifically with probability and ratios. There is a method to better understand probability outcomes that includes current and prior knowledge. Formally known as Bayes’ Rule (aka, Bayes’ Theorem or Bayes’ Law), it provides a way to numerically express how a degree of belief should rationally change to account for evidence of that belief. It gets complicated but basically, it involves prior and posterior probability.
The posterior probability is the Bayesian inference. The value in using Bayes’ Rule is starting with a prediction, getting results and then improving the prediction based on those results. What I find interesting is it provides a way to get smarter about something in the future and uses a ‘closed loop’ to do it. The intent is to keep getting smarter based on what you know and what you learn.
Improved insight or knowledge may not require using Bayes’s Rule, and whatever form is used for communications, it is important to accurately state what you know and reserve the right to be smarter in the future.
Ruminations on Change Control October 22, 2014Posted by Edwin Ritter in Project Management.
Tags: Change, change control, process, project deliverables, project experience, project management
add a comment
It seems that no matter how much project experience you have, how talented your team is and how simple or complex a project is, there is one thing that will always be constant and that is change.
Previous posts of mine have dealt with setting up projects, closed loop feedback and the value of PMOs. Another basic process to define and get agreement on while setting up a project is how to handle change. The concept again applies to ITIL, Project Management and Lean Six Sigma areas. The level of process to use in review and accept/deny changes can be proportional to the complexity of the project. Simple projects don’t have many changes while complex projects can have multiple changes. This relates to the fact that we make decisions and plans at a point in time. As the project goes forward and we get smarter in the future, we may need to revise our plans and that can lead to change.
In fact, during the planning phase, the process details should be documented to submit a change, review and assess the impact to the project. There are as many ways to deal with change as there are organizations. Having a consistent way to deal with and manage change(s) to a project is essential when change occurs. This chart illustrates the basic concepts as just one example of the process. Using a common repository, change log or application to create the change record is a good practice also.
The PM works with the project team to provide an impact assessment and a recommendation on the change. That decision should be reviewed with the sponsors. Each change should be assessed for impact to the schedule, resources and budget. Here are six steps to control change:
- Record / Classify – capture the request and indicate what area(s) of the project are affected
- Assess – review the impact to the cost, schedule and resources to implement
- Plan – update project documents as appropriate based on the assessment
- Build / Test – execute the change and determine effect to the rest of the project deliverables
- Implement – include as part of the project deliverables and release at go-live
- Close / Gain Acceptance – complete the documentation on the request and communicate with the team and stakeholders.
Using the process framework provides a way to control changes for a project and the rate at which changes are generated. Here is where the process helps in that it provides a way to accept or deny changes. Completing an assessment of the change and updating plans result in data to support the resolution to the change request. Not all changes are created equally. Some can be rejected outright and from other requests, it is clear to see the benefits.
Last, during project wrap-up and lessons learned, the number of changes submitted and their resolution can provide some interesting insights. How many were submitted? Accepted? Did the changes requested indicate a gap with requirements? Was the project not planned properly? Was the design not fully thought out? Those questions and others can lead to animated discussions. The key is which ones to action and improve on going forward.
Of course, that could be a change request also. How do you manage and control change? Does the process impact your project in a big way? What happens if you reject a change? Comments invited.
Ramblings on RACI Matrix for Projects September 25, 2014Posted by Edwin Ritter in Project Management.
Tags: ITIL, matrix, project management, project manager, RACI, RACI matrix, six sigma
A lot of things need to occur to get a project started. For the project manager, understanding the basics about the project – the goal, timing, budget are some of the tasks to getting organized. Included in that understanding is who will do what tasks for the project.
A great way to get organized and develop that overall understanding about the make up of a project is to document. No, really, it is. There are several basic documents that come to mind. As separate and distinct files, those include the scope, charter, schedule and raci matrix. Each of these is important for upfront planning and also during execution of the project. I have found that writing or contributing to each of these is very helpful. Being able to communicate the knowledge of the what, how and who during a project kick-off meeting helps get the team up to speed quickly. Most of the documents are easy to understand conceptually by their title. The last one, the responsibility matrix thing, might be a bit unclear.
Essentially, the raci matrix lists who is responsible for what on a project. As an acronym, it stands for Responsible, Accountable, Consulted and Informed. A brief definition of each will assist in why this document is useful for the project manager, the team and stakeholders.
Responsible – Those who do the work to achieve a task. There is typically one role with a participation type of Responsible.
Accountable – Those who are ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom Responsible is accountable. Typically, the Process Owner is Accountable for a process, and there must be only one Accountable specified for each task or deliverable.
Consulted – Those who are not directly involved in a process but provide inputs and whose opinions are sought.
Informed – Those who receive outputs from a process or are kept up-to-date on progress, often only on completion of the task or deliverable.
There is a variation that includes another role for support. There are templates available for a RASCI as well. The ‘s’ stands for support and the definition is :
Support – Resources allocated to Responsible. Unlike Consulted, who may provide input to the task, Support will assist in completing the task.
The RACI matrix is not only used in project management. It is used in other IT processes and methodologies. The RACI matrix is part of the ITIL process for service design and driving service improvement. For Six Sigma methodology, the RACI matrix reflects the basic principles of the process.
Having a RACI helps everyone understand the specific interactions and dependencies involved with the who and what on a project. The RACI matrix is useful for communicating across the organization when a project needs support. This can be very useful in matrixed organizations and reduce the overall time required to get resources.
On this sample, you can see the project manager is accountable for almost everything. Additionally, you can see what each person on the team owns and will drive to completion. A subtle point here in that it also indicates what tasks each person should plan, be involved with for, or otherwise be aware of. From my experience, it also visually emphasizes teamwork and that a team effort is required to deliver the project. Note – the astute among you will notice that the example matrixes shown in this post are transposed. However they are oriented, the concept remains the same.
Comments invited on this tool in project management, ITIL or Six Sigma.
Ruminations on work life balance August 22, 2014Posted by Edwin Ritter in Behavior, Grab Bag.
Tags: leadership, management, time off, vacation, work life
add a comment
Labor Day is right around the corner as we approach the end of another vacation season. Taking time off is an important part of the balance between work and play. Going on vacation is beneficial for multiple reasons and mental health is a primary one. Companies like to proclaim how important employees are and that having paid time off (aka, vacation) is a benefit they (sometimes grudgingly) provide. We all look forward to the annual summer sojourn to a familiar place. Or, the thrill in going to new places while taking time off.
So I find it interesting the strong reaction people have when the media reports our elected officials have vacation plans. Not only plans, but, actually going on a trip for vacation. The shock, the disappoint from people when a state senator, city mayor or even the president takes a few days to recharge.
Why are we surprised by this? Do we really expect politicians to work all the time? Of course not. However, there is perhaps an unrealistic expectation that a politician will stay at work during a crisis or when there are lots of events that may require their attention.
Consider the furor from two recent events. One involved NYC Mayor, Bill DeBlasio. He and his family planned a trip to Italy. The timing of this trip upset many residents who use mass transit. The nerve of him planning to leave the country while there is the threat of a transit strike. He should be at work!
A second event involved the POTUS. Aka, the President of the United States. Critics state he should not go on vacation while there are issues in Ukraine, Middle East and Ferguson, Missouri. He needs to be in the oval office. Taking vacation now is in poor taste, shows bad judgement.
Hold on. Everyone likes to go on vacation. We eagerly look forward to taking time off. Studies clearly show the benefit in maintaining a work balance with life outside the office. This applies to everyone regardless of their job. Also, our elected leaders are never really out of touch with current events. Not anymore. They may not be in the office yet staying connected has never been easier. Politicians, like the rest of us, can and often do, work remotely.
Taking a few days off is not so dire. Consider a vacation from 1927 with then President Calvin Coolidge. He and his wife spent three months in the Black Hills of South Dakota. Three months! Taking that amount of time off today is unthinkable. How times change.
Great leaders can, and should, delegate effectively. When done well, we do not notice a difference. How many times has a co-worker post poned vacation plans to stay at work? Was it really necessary? I say, enjoy your planned vacation and let our leaders do the same.
By the way, how was your summer vacation? Do anything exciting?
Enjoy the long Labor Day weekend and the time off. Comments always invited!
SMART Requirements July 9, 2014Posted by Edwin Ritter in Project Management.
Tags: assumptions, process, project management, requirements
add a comment
I’ve been ruminating lately on the interplay of the following : assumptions, requirements and expectations. Whenever we interact, being a good listener and confirming what you heard are key to meaningful conversations. Segue to a snippet of dialogue from a favorite movie scene :
Man: “You’d better tell the Captain we’ve got to land as soon as we can. This woman must be taken to a hospital.”
Woman: “A hospital? What is it?”
Man: “It’s a big building with doctors and patients, but that’s not important right now.”
Which reminded me of SMART*. A quick search led me to this blog which captures what I agree with on the having clear, defined expectations and the big ‘R’ word, requirements. It should not always fall to the project manager to sort this out of course. Sponsors and customers can be SMART. Wouldn’t that be nice? Which implies process and management styles – a topic for a future post.
*Common definition for SMART: Specific, Measurable, Actionable, Reasonable and Timed
How often are your projects SMART? If you asked for that as a requirement, what are your expectations for a response?
Originally posted on The Practical Project Manager:
In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.
Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer…
View original 1,658 more words