Tag Archives: project

Enable VMware EVC by default on your new vSphere Clusters

If you don’t have a compelling reason to not enable EVC on a cluster, then I don’t see why you wouldn’t enable it. EVC allows you to future guard your cluster so that it allows you to introduce different CPU generations on a cluster.

There has been no evidence that EVC negatively impacts performance. But like with anything you should trust, but verify the application workload has the acceptable level of performance that is required.

There are impacts as to whether you have enabled EVC on an already existing vSphere cluster with running VMs. There is no outage if you do decide to turn on EVC on an existing cluster, but running VMs will not be able to take advantage of new CPU features until the VM is powered off and powered back on again. The opposite will occur if you decide to lower the EVC on an already EVC enabled cluster so the VM will be running at a higher EVC mode than the one that was explicitly lowered to until the VM is powered off and powered back on.



Using the Socratic Approach to Problem Solving

Using the Socratic Approach to Problem Solving

Applying a Socratic approach to problem solving can help to identify gaps and improve problem solving. It can help to spark new insights to produce further knowledge of the problematic area of interest. This approach focuses on asking a person a series of open-ended questions to help promote reflection.

Step 1: Identify the elements of the problem, issue or question

Things you may do in this step may include:

  • Breaking the problem down into pieces, elements or components.
  • Look for missing information or gaps in what you know.
  • Make note of the information that you don’t have or can’t find

Questions you may ask in this step include:

  • What is the problem you’re trying to solve?
  • What information is missing?
  • Is it possible to get the information that I don’t have?

Step 2: Analyze/Define/Frame the problem, issue or question

Things you may do in this step may include:

  • Decide which pieces of information are important
  • Avoid premature solutions
  • Identify the complexities of the problem

Questions you may ask in this step include:

  • What am I trying to solve?
  • Is the information so far gathered relevant to the problem?
  • What are all of the possible causes of the problem?

Step 3: Consider solutions, responses or answers

Things you may do in this step may include:

  • Analyze possible solutions
  • Check the implications of each possible solution

Questions you may ask in this step include:

  • Are there any other possible solutions?
  • What might be the consequences of these solutions?

Step 4: Choose an actual solution to implement

Things you may do in this step may:

  • Question your choice of solution
  • Consider the problems that may result from your choice

Questions you may ask in this step include:

  • Why do I prefer this solution as compared to the others?
  • What are the possible risks of this solution?
  • How is this solution supported by the facts so far?

Step 5: Implement your choice

  • Monitor the progress of the implementation

Step 6: Evaluate the results

  • Did I solve the problem?

This is just one way to go about solving a problem when you get called into a situation where you need to solve a problem. There are other ways to skin the cat but this one is easy enough to follow and can provide some fruitful information to help solve the problem

Requirement Elicitation

Some of the challenges associated with requirement gathering or elicitation happens in the development life cycle. During the beginning stages, it is of the utmost importance to get a good grasp of the requirements. Getting the requirements wrong or not properly captured can set a project up for failure from the beginning.

This YouTube video is funny because some of us have been there: https://www.youtube.com/watch?v=lXNu0VBVCUc

Requirements gathering is all about determining the needs of the stakeholders to solve a problem or achieve an objective. Once the needs have been identified, then it’s a matter of succinctly identifying the specific requirements while minimizing any assumptions. Sometimes an iterative approach helps the process by continuously checking in with the stakeholders throughout the project to determine if the progress is meeting their requirements. The amount of iteration depends on the complexity of the project.


Requirements can be broken down into functional and non-functional requirements. A functional requirement specifies what the system should do. A non-functional requirement specifies how the system should behave. A method for requirement prioritization is the MoSCoW technique in which you break up the requirements into:

  • MUST (M)
  • SHOULD (S)
  • COULD (C)
  • WON’T or WOULD ( W )

This is a good step to help prioritize those requirements so that you know what to focus on the most, which is the must haves. On top of the requirements you also can’t forget the assumptions, constraints, and risks.


Working in a Virtual Team

In this sense, a virtual team is one that is made up of people in different physical locations. I’ve worked on different projects that required the use of virtual teams. I’ve had a love/hate relationship with them in the past. Working in a team is not easy in general, so working in a virtual team raises the level of difficulty one notch up. By no means is it impossible, but it takes some work to make it successful.


One of the challenges is deciding on the best use of the technology platform that works best for everyone. The use of mobile technology makes it a menu of choices to pick from. Some people argue that the lack of face-to-face interaction is lost, but to that I say WebEx video, Skype video and FaceTime can take care of that. The other challenge is if the team is spread out into different time zones then that the scheduling of meetings becomes an issue.

The challenge of working in a virtual team can be an opportunity to bring in a diverse set of viewpoints and experiences that team members can contribute. I believe that as long as you have good communication skills, then working in a team, whether traditional or virtual team will not be a problem.

This HBR article gets a lot of points right in relation to virtual teams: https://hbr.org/2014/12/getting-virtual-teams-right

IT Risk Mitigation

Every IT project brings some level of risk. Risk mitigation is about understanding those risks that can impact the objectives of the project. Once that’s identified, then you need to take the appropriate actions to minimize the risks to a defined acceptable level to the customer. Taking those deliberate actions to shift the odds in your favor, thereby reducing the odds of bad outcomes.


At times risk management is an active process that often requires a large degree of judgement due to insufficient data. The architect has to make certain assumptions about the future. Technology is a source of risk and its often due to the unintended consequences. For this reason, you must validate that your mitigation is resolving the identified risk.

Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability and the resulting impact of that adverse event on the project.


So, in order to effectively manage the risk, then one must identify the risk, assess the risk, respond to the risk and then monitor the risk.

I was in a project meeting recently and the project manager was asked what were some of the risk identified. The PM responded with none and the whole room sat silent for a few seconds. Then he went into his risk log list and the whole room chuckled a bit.