#155: Give Them Faster Horses

give them faster horses

Give them faster horses! I say this tongue and cheek. Only to make the point that as technology professionals we have to lead the innovation in our organizations. Not just take requests from our business partners. We have to become as knowledgeable about the businesses our organization is in as the our business partners are. This week on CIO Playbook with Jeffrey Hurley, I am suggesting that you can lead innovation within your organization and still focus on budgets, projects, support, and keeping the network up.

Technology is the Innovator

Henry Ford is is often quoted as saying, “If I had asked people what they wanted, they would have said faster horses.”

When it comes to innovation there are two sides to the approach. One side vehemently argues the merits of innovating via customer feedback. The other side argues that true innovation is created by a singularly gifted visionary who ignores customer input and instead manufactures innovation based solely on their prophetic vision for a better future.

When I think of visionary innovators it is Henry Ford, Steve Jobs, Nick Woodman, Richard Branson, Elon Musk and many more. Many of these innovators come across larger than life. To disrupt an entire industry often the talent is being larger than life.

So, what do we do as members of a technology organization to press innovation forward if we are not the type to be larger than life. In Japan they have the concept of Kaizen, which is the practice of continuous improvement and should be considered an key to your organizational competitive strategy.

Honda does this very well and is consistently a market leader. We don’t look at their cars as breaking any molds and as design leaders, yet they consistently produce high quality market leading products. General Motors is a market leader also, yet they are not known for continuously improving their product. They do take some design risks, though many tend to be in the wrong direction, I will cite the Pontiac Aztec as a revolutionary design in the wrong direction.

Caught Sleeping

When we look to press innovation and technology forward we are often met with the greatest resistance from our Finance organization driving the need to meet budget expectations and project immediacy versus the strategic innovation that enables us to leapfrog our competition. Today we are seeing innovation like never before, yet the challenge is how to effectively innovate, getting out of the forest and weeds and up above to see if we are even in the right forest.

In every organization you can find people of innovation, even in the tightest budget environment. I hope you became a technologist because of the cool things you can do with a computer.

Apple and Steve Jobs did not create music, mp3 players, mobile phones, cameras, or watches. Yet, Apple transformed what was in the market and found solutions that resonated with their customers.

When mobile devices came into our organizations they were brought by the business partners. The majority of technology organizations were caught unprepared to support them. We have to build for the future while meeting the immediate business needs.

Get Out of the Rut

Now let’s look at the personal camera and video recorder markets. The smart phone has placed immense pressure on these markets. Yet, GoPro succeeds in a niche and is rewarded accordingly. While Cisco purchased flip video in 2009 only to close the business down in 2011. Cannon, Sony, and others don’t seem to have a reasonable equivalent to the GoPro.

These companies were giving the customers faster horses, essentially staying in a fixed range with their camera innovation. While GoPro and smart phones transformed the market. Where was the problem? Is there a lack of out of the box thinking or is group think standing in the way of innovation?

A Vision for the Future

Do you wait for a market trend to emerge? Or, do you become a trend setter and market maker?

A vision for what the future can bring can come from many sources. To spark your innovative thinking read the science fiction novels, look to comic book characters. Seek out the locations where innovators are hiding in your organization. Look to break down your existing organizational constructs to “free things up”. Look for opportunities to go off track.

I understand that in a technology organization our challenge is to contain scope creep and staff choosing enhancements over projects. You as the leader will want to find that balance. Creating an outlet for innovation among the staff. If your organization is constrained by budget and staffing find ways to create small skunk works teams that will work outside of the standard office hours.

Or rather than building a better mousetrap during requirements gathering observe your businesses and propose radical new way to do the work. Rethink the work and ask why. Map the “as is: and eliminate or automate they processes. Don’t accept things as they are look at how they could be.

It’s Your Move

How do you build for the future when your partners just want you to give them faster horses? It is your responsibility to build for the future. Establish a visionary agenda and push for change, while demonstrating that you are meeting the current business demands. If you are not the one to drive technology innovation in your workplace it will be brought in from the outside.

Yes of course there is risk in calling yourself out and pressing for change. Yes, you will get resistance. It is the true leader and visionary that is able to overcome the resistance and show the benefits of change. Bring everyone around to your way of thinking about the future. There is very little in the way of options left is technology is not driving the organization forward as a true partner to your business teams.


Photo Credit: Duggar11. “Hot Springs, Arkansas – 1915, Ice Wagon.” Flickr. Yahoo!, 8 Jan. 2011. Web. 28 June 2015.

#154: The Integrator’s Dilemma

Integrator's DilemmaThis week on CIO Playbook with Jeffrey Hurley, I am discussing the integrator’s dilemma. The challenge technology professionals face when working to integrate third party applications in their environments


The Proven Process

When we look to bring on a 3rd party technology solution we are looking for the most cost effective time to market approach to getting the system implemented in our environment and our business teams incorporating this technology into their process

The Approach: The Integrator’s Dilemma

The integrator’s dilemma comes into play when you and the vendor are working out the initial negotiations. Attempting to come up with reasonable estimates for total cost of this new technology and looking for the best approach to getting the system in.

Not having complete information at the time of contract negotiation many of the professional services teams will work to avoid a fixed price for implementation. Especially if you have an existing “heritage” environment that must be addressed as part of the success criteria. If you are implementing into a greenfield the basic implementation becomes straight forward. However, the majority of opportunity for third party technology to make an impact is in the developed markets where the common underlying system solution is competitive neutral. in other words implementing a third party solution will keep you market competitive by delivery market needs and a lower cost than maintaining an in-house developed solution.

For an organization to be “reinventing the wheel” with in-house development in a global marketplace would be tantamount to setting itself up for failure. Only in the areas where there is clear competitive advantage should an organization be doing custom development. And as a technology leader, you have the responsibility for designing a solution that is easily replaced when the competitive advantage becomes “market normal”


Planning your implementation always starts with determining the “source of truth” for data in your current systems. Will your system, that you are implementing, be the “source of truth” or will it be pulling from alternative systems that will have the “golden copy”. Often when an organization begins an integration project it quickly discovers that there isn’t a single “source of truth” and that many departments and functions are using their own version of the data.

Part of an implementation should involve establishing a single “source of truth” for the organization.The particular implementation you are doing will not be responsible for changing all systems to the identified “source of truth” rather the idea that this can be established is an excellent outcome and the organization and technology can move in the direction of the established “source of truth” over time.

Now ever integrator and software vendor should have an established and battle tested plan of integration that entails, installation, “out-of-the-box” configuration, data loading, and system integration APIs. A practiced integration system should have a TAR file that can deploy all components and the execute a script to populate a working system with the basics.


It is at this point that we move to the implementation phase. Starting with system configuration for user groups, offices, security rules, workflows, basic screen and GUI. While these steps are going on a parallel exercise should be taking place that is focused on the data loading involving hierarchy design, aggregation, and cleansing activities.

Being ready to deploy to the full user base can take anywhere from a few weeks to 18 months depending on the magnitude of the system you are deploying and the amount of integration or data conversion that will need to be done.

Often in the larger institutions the legacy systems are what holds the organization back. When a new system is brought in, getting the existing data and workflows into the system are so onerous that it makes sense to start fresh with the new system. Changing the workflows to match the new system’s approach. Then copying the historical data into a reporting database rather than attempting to convert it into the new system. The resulting outcome leverages the market leading practices and allows the organization to release the “old way” of doing things.


The deployment phase becomes the key to getting the organization moved over to the new business process and technology solution. This is about “go-live” with your user base and training your users as they are on-boarded. I mention training because one of the larger challenges a help desk function faces is “user error”. User error is caused by lack of or abbreviated training.

It is during the deployment that you are building a support process of the long term maintenance of the system and the user base. This is your data governance, how communications will happen, and on-going training. Optimization will be focused on deepening these areas.

When the integrator is deploying the system the goal is to ensure maximum value for each user group in the organization. Often this will entail specific training for the particular user group be deployed to.

It is during this deployment that user input should be collected to identify the optimization, integration, and enhancements for the next phase of the project. The advanced functionality and analytics are often included in the second phase of the integration project.


Once your system is deployed to the user base the work is not done. Now it is learning how to optimize the solution for your organization’s environment. Maximizing the return on investment comes from recognizing the opportunities to alter the standard configuration or leverage the new data collected.

The modern systems architecture is designed around the capturing and analyzing of data. If you are implementing a new solution the optimization will be focused on determining which data elements are providing the most value in understanding your customers, your organization, and the efficiency in your processes.


Finally, moving from integration to on-going business as usual will bring the integration program to closure and move into the phase of managing your system for the organization. This will entail the on-boarding and off-boarding of users, training, enhancements, analytics, and upgrades. Investing time and effort into getting the support right and continued optimization will continue to provide your organization with the advantages it sought in implementing the third party solution.

The Integrator’s Dilemma

Almost all system implementations have some form of the software development life cycle as their basic layout. The question really comes down to the organization’s uniqueness, data quality, and legacy systems. If these three can be properly managed throughout the process the planning, implementation, deployment, optimization, and support will get you there. However, it is more often a challenge in one of the three areas that is cause for cost over-runs or delays in the project.

Strong leadership from technology and business management will help to advance your organizational goals and reduce the dilemma of an implementation.


Photo Credit: Michel. “Wisest Advice.” Flickr. Yahoo!, 26 Dec. 2014. Web. 12 July 2015.

#153: Part II Business Requirements

business requirementsThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part II of how to develop your business requirements.

I mentioned in last episode that there are multiple layers to project management and often the project management office tended to over paperwork versus project delivery in their focus.I then walked you through a business requirements document that I prefer to use in my organizations. Finding that consolidating multiple templates and forms into a more concise document tends to both create a document that will get read by stakeholders as well as get the technology team to work sooner.

This week we are focusing on completing the last few sections of the business requirements and how to incorporate the document into your project management process. I will show how working with your project managers and business management using a business requirements document will improve communication and delivery expectations. Then we will look into what it takes to maintain a business requirements document and conclude with you incorporating the document into your next project.

Interface Business Requirements

Almost every system will have some form of interface with other systems. This could be for the entitlements and people access through to data exchange between source and destination systems. It is in this section of the requirements document that these interfaces should be called out.

Business Requirements Revision Log

Business requirements documents tend to be evolutionary and will have multiple revisions before they are signed off and sometimes they will have to be circulated for signature after a major revision. Therefore it is important that a document of this nature maintain a revision log so that older versions can be reviewed and readers will know which version they are reading and referring to in discussions.

Business Requirements Approvals

Finally the business requirements document should have an approvals section where key stakeholders will sign off their agreement to the business requirements. This sign-off can be simple and contain sponsors and leaders or a much broader list of stakeholders. Either way a project should not proceed without these sign-offs in place.

How do You Use Business Requirements

A business requirements document is a communication tool. The human brain has limited capacity to remember much of what is said. Therefore it is important to write down expectations and needs of a system to enable the various teams to be on the same page with the business objectives of the application being worked on.

Business requirements will provide a method for testing ideas on paper before investing in tools and technology that may not meet the needs of the particular business situation.

Does Leadership Use Business Requirements

Investment in information technology is not inexpensive and therefore ensuring all stakeholders understand what is desired from the system both in effort and benefits it is easily to approve the dollar spend along with maintain the support over a longer period of a major strategic project.

What Role Do Business Requirements Play in a Project

One of the greatest challenges to projects is scope creep. Business requirements with their in scope and out of scope sections will help reduce the challenge of scope creep by the nature of calling out directly what will be and won’t be completed. In addition the active management of document revisions will call out any frequent changes happening which will allow management to take a more active involvement in the change management process.

If a document is changing frequently then a project may have issues with ineffective requirements or a constant stream of new opportunities preventing an effective delivery and as a result impact the organization’s ability to meet its objectives.

How do You Maintain the Business Requirements

I find that requirements can be simply maintained in MS Word or MS Excel. I have seen numerous third party applications that can maintain multi-layers of project documentation meeting PMI, TOGAF, ITIL and other technology frameworks. I have found that while these frameworks are impressive, in their documentation, it is hard to incorporate them into an organization effectively without significantly increasing the technology overhead.

Thus I find that a source control system for the MS Word or MS Excel document will work fine for maintaining the various versions of the documents as they evolve over the life of the project.

In Conclusion

To wrap of this business requirements series I am hopeful that some of what I talked about in these two episodes will lead to you making a change in how you are looking at some of your project documentation. Consolidating the plethora of available documentation into a set of concise tools that will improve team and stakeholder communication and shorten the time it takes to move from analysis to delivery.

Let me know how you are using your business requirements..best of luck,


Photo Credit: US Dept of Agriculture. “A Variety of Dried Ingredients.” Flickr. Yahoo!, 16 Mar. 2014. Web. 05 July 2015.

#152: Part I Business Requirements

business requirementsThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part I of how to develop your business requirements.

I have found that a lot of project management teams or project management offices tend toward the overly paperwork and bureaucratic approach to project delivery. This is unfortunate because project management can be a strong value add to the delivery of technology solutions.

When I embarked on this series on project management and project delivery success my goal was to provide a minimalist view of how to ensure successful project delivery. I believe we need oversight and reporting to provide the necessary visibility into the progress of our projects and any potential roadblocks to achieving success.

I am a technology leader who came up through the ranks of development and as such was often stymied by those who sought to document the work before we embarked on it. This, more often than not, contributed to the slow down in technology delivery and, at the time, I believed wasn’t needed. Many organizations today still struggle with whether they want the overhead of project managers and business analysts. I now see there is value in having analysts and managers dedicated to project analysis and delivery, ensuring that the business needs are identified and met throughout the delivery process.

Which brings us to today’s topic, business requirements. I have worked with many types of requirements documents and a quick google. will bring up a very large set of results with the many ways you can structure your requirements. Documents from simple written statements to multi-page traceable manifestos, deemed business requirements documents. Both of these styles represent extremes on the spectrum of business requirements, yet somewhere in between is a highly successful tool for delivery of a viable business solution.

I am going to walk through several levels of business requirements documentation; hoping to give you a tool analysis for your organization to realize project success.

The Business Requirements Document

The business requirements document consists of several sections.

  • Introduction
  • Scope of the Requirements
  • Functional Requirements
  • Data Requirements
  • Non-functional Requirements
  • Interface Requirements
  • A Revision Log
  • Approvals

Now let’s step through these categories and talk about how they function in building the requirements.

The Introduction Section

The introduction section of the business requirements sets the purpose, essentially telling the reader it is a business requirements documents and its goal is to describe the requirements of the software application as completely, accurately, and in a technology independent manner. The intended audience is then described, which should be the business owners and should be readable by business owners and the implementation team.

The next area of the introduction is the project background, giving the reader an understanding of how the project came into being and received its priority ranking. Often it is in this section that describing the type of requirements

  • Enhancement to an existing application
  • A new application
  • A replacement application

What are the major goals or objectives of that are targeted with the implementation of the business requirements. Are their any significant business benefits that can be achieved by the implementation. What are the known risks, assumptions, issues, and dependencies.

My mention of risk, assumptions, issues, and dependencies is an important part of the requirements. placing these in a section at the front of the document so they can be tied to the business requirement will not only increase the visibility to the stakeholders it will provide an easy way for the project manager to pull them into her log.

The Scope of the Requirements

The scope of the business requirements section is where the defining what will be accomplished and what will not be accomplished is done. As an author, reader, or the technology team that will consume this document it is important to understand what is defined by the use-cases that are within scope. At the same time there should be use-cases in an out of scope section. This way both business and technology teams have a clear understand of what is in scope and what is out of scope for the particular project being worked on.

The Functional Requirements

Here is where I divert from a lot of project management offices. I believe the functional requirements should be a part of the business requirements document. There is no need to produce multiple documents and in many cases repeat what has already been written on the topic. In the scope section I suggested the use-case approach and it is in the functional requirements section that we draw up the detailed stories of how the system will work.

The use case process will involve profiling the actors within the context of the business requirement. An actor is external to the system they are interacting with. the actor interacts with the system by providing input and/or receiving some measurable output from the system. The functional requirements will include an essential use case diagram, essential use case specifications, With the specification being the written form of the use case.

The functional requirements should conclude with the business rules that are applicable to the proposed system

The Data Requirements

All systems require data and the business requirements document should outline the data requirements for the system. Starting with the data architecture, which tends to be a more technical in nature, however it is key to understanding system sizing.

Outlining the data volume expectations early and over time will enable the technology team to resource the correct hardware and network solutions to ensure a smooth scalable solution. Data conversion, which is often the most difficult part of the project, should be outlined early as it will impact project timelines and costs. What type of data retention and privacy will be required of the system.

Non-functional Requirements

A non-functional requirement is typically a requirement that is not easily specified in the use case format. For example some non-functional requirements can include legal, regulatory, and compliance requirements. Application standards including reliability, performance, and the support needs are outlined in this section.

Every system has to have security and entitlements and authentication requirements should be described as par to the business requirements. When it comes to logging activities of users of the system transactions can be anonymous, pseudonymous, identified, and verified.

Many in house systems forget to include a help requirements and as a result often offer minimal end use help features. In your environment help features may be important to the use of the system and should be described as part of the non-functional requirements section.

Finally the non-functional requirements section will include system performance expectations and scalability for higher or lower than expected volumes or business growth.

Next We Will Continue With…

  • Interface Requirements
  • A Revision Log
  • Approvals
  • How do You Use Business Requirements
  • Does Leadership Use Business Requirements
  • What Role Do Business Requirements Play in a Project
  • How do You Maintain the Business Requirements

Until next time….


Photo credit: Baird, Mike. “5 of 5 Long-billed Curlew.” Flickr. Yahoo!, 17 July 2008. Web. 28 June 2015.

#151: RAID Log Part II

RAID LogThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management with Part II of how to use a RAID Log to manage some of the key priorities that could potentially derail your project success. I mentioned in last episode that there are unknown events and events out of your control creating risk to your project success, however, knowing in advance what these events are gives you the opportunity to develop contingency and mitigation plans. This week we will focus on how to incorporate the RAID Log into your project management process. I will shoe how working with your project managers and business management to leverage the RAID Log to ensure roadblocks are removed. Then we will look into what it takes to maintain a RAID Log and how quickly you should have contingency and mitigation plans in place to protect the project deliverables.

How Do You Use a RAID Log

  • Weekly Meetings: As part of your weekly work stream meetings team members should be bringing up the risks, assumptions, issues, and dependencies they have identified during the period between this and the last meeting. Active team members will be sharing their latest discoveries, progress against current identified items, and key mitigation activities.
  • Steering Committee: The steering committee plays a key role in project success by bringing together senior business and technology people who can make decisions and take necessary action to remove roadblocks. The RAID Log has a category for risks, assumptions, issues, and dependencies that should be managed at the steering committee level. These tend to have the greatest probability, severity, and corresponding impact on the project timelines and budget. The steering committee update should include regular statistics on the RAID log including dollars being spent on the mitigation and contingency planning.
  • Status Updates: Status updates can include totals on the opened, in progress, and closed RAID items and should be made available to a broad audience. With some more specific items, included in the status report, that involve the larger stakeholder participation to ensure mitigation is happening.

What Does Management Do with the RAID Log

The purpose of the RAID Log is to raise awareness of the risks, assumptions, issues, and dependencies project wide. Giving ample time and awareness to ensure ability to address them before they become active and result in impact on the project’s ability to meet deadlines and scope expectations. Management has the responsibility to be reviewing this log on a regular basis and providing roadblock removal services.

Management and business leadership are import drivers in addressing RAID Log items, given the nature of their role in the business leadership and setting of strategic direction. The project you are running and the technology you are implementing should be enables of the business strategic direction. As a result management discussions and approval can often correct or address many of the RAID Log items.

How do you Incorporate a RAID Log Into a Project

As I have argued, the RAID Log is a key to successful project management and delivery. Updates to the log should be made from the start of the project all the way through to the end of the project. My recommendation is the project manager should be updating the log when she updates the project plans, finishes a meeting, summarizing minutes, and after completing the weekly status reporting. The RAID Log is as important as the project plan and therefore must be kept current throughout the whole project.

How do you Maintain a RAID Log

I suggest setting up a RAID Log in MS Excel and then sorting and copying for use in your PowerPoint updates. The log is really a point in time or current status log rather than a historical or progress based tool. A RAID Log item once identified should be mitigated and open and close dates tracked. Often a RAID Log item will remain open for the duration of the project. Therefore the log should be updated prior to a weekly work stream review meeting (at least once a week) and prepared for the steering committee updates.

How Quickly Should Items be Mitigated or Resolved

This is the “it depends” answer section. Because the RAID Log really does depend on what the likelihood of the event: risk, assumption, issue, or dependency happening or not and the potential damage to the project. that is why you assign a probability and severity to each of the items on the log. Determining how important it is to address the item quickly or monitoring it for a period is where your talent as a leader comes in. An item identified and observed is often enough all that is needed to mitigate it, while other times you will require a proactive intervention to prevent the potential damage.

To Conclude

the RAID log is a key tool in your project management tool box for identifying and managing items that can derail a project. By effectively using this tool and increasing visibility to the broader stakeholder community you can increase the opportunities for early identification and assistance in the mitigation of these potential derailers. Expand your risk and issues log in your next program or project and observe the results for yourself.


Photo Credit: Disco-Dan. “Fan Bay Deep Air Raid Shelter And Magazine Room.” Flickr. Yahoo!, 15 Feb. 2013. Web. 14 June 2015.

#150: RAID Log Part I

RAID LogThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management with how to use a RAID Log to manage some of the key priorities that could potentially derail your project success. Unknown events and events out of your control are always a risk to project success, however, knowing in advance what these events are gives you the opportunity to develop contingency and mitigation plans. Understanding how to categorize risks, assumptions, issues, and dependencies will move you in the direction of greater project success. I suggested managing your projects with the raid log as a key component of the regular update meetings; whether these meetings are with the working groups, stakeholders, of steering committee members.

What is a RAID Log

A RAID Log is a component of the project management tool box. This log is the risks, assumptions, issues, and dependencies for the project. A central place to track the key components or influences of your project’s ability to deliver on time and to expectations

Why a RAID Log and Not Something Else

There are multiple items that can have a negative impact on a project. Usually there are solutions to these items if you have time to plan for them up front. Much like practicing your building’s evacuation plan, a project can be protected if mitigation plans are in place well in advance of any items on the log happening. If something on the log cannot be mitigated at a minimum the project and business leadership can be aware of and prepared for the event should it happen.

How Should You Set up Your RAID Log

If you google RAID Log both using the web or images options you will discover there are many ways to structure these logs. I have found that there are a couple of key items that need to be a part of the log and then depending on how you want to manage your project you can add additional fields. My personal preference is to provide a series of fields that allow for easy filtering in MS Excel. you could build or buy an application to this as well. However, I have found MS Excel works just fine and that means google docs and Libre Office, etc. can be used to develop these logs if you are looking for something less expensive than the Microsoft suite.

Overall Impact Guidelines

  • Critical: Item is required to be escalated to Senior Management with mitigation options if possible
  • High: Management item to be monitored by the project manager and senior management
  • Medium: Item for project managers to monitor and does not require escalation
  • Low: Item to track for awareness and monitor if it needs escalation

Severity Guidelines

  • Very High: Will impact the deployment date
  • High: Could drive impact to deployment date
  • Medium: Could drive impact to intermediate milestone, which could impact deployment date
  • Low: Could drive impact to tasks and may impact an intermediate milestone
  • Very Low: Could drive impact to the project milestone that could easily be absorbed by the project (non Go-live time)

Probability Guidelines

  • Certain: 100% likelihood of occurrence
  • Expected: Greater than 90% likelihood of occurrence
  • Likely: 60 to 89% likelihood of occurrence
  • Possible: 40 to 59% likelihood of occurrence
  • Unlikely: Less than 39% likelihood of occurrence

Status Guidelines

  • Open: The item is being actively monitored and tracked
  • No longer relevant: The item has been investigated and is of little or no concern
  • Closed: The item is closed

Risk Type Guidelines

  • Governance: Related to program / project management, approvals, committees, etc.
  • Business Process: Related to business process or procedures
  • Software / Hardware: Related to software design and development or hardware, network, or enterprise systems
  • Training: Related to process or system training
  • Testing: Related to system testing and user acceptance testing
  • Adoption: Related to system integration and adoption into the daily business activities
  • Team / Resources: Related to program / project staffing: vendor, information technology, business teams, etc.
  • Communication: Related to information sharing and transparency for the program / project
  • Other: Any risk, assumption, issue or dependency not defined by the reset categories

Risk / Assumption / Issues / Dependency Guidelines

  • Risk: A risk is the recognition that a problem might occur that may potentially interfere with the successful completion of a project. Risk is anticipated in the future which will require mitigation.
  • Assumption: An assumption presumes that a group or deliver will happen, is true, or certain. If this assumption does not come true the project will have an impact. There is a subtly between an assumption and a risk
  • Issue: An issue is something that has already happened in the project and a solution to resolve it is being looked for; a mitigation plan is needed
  • Dependency: There are four types of dependencies upstream internal dependencies, upstream external dependencies, downstream internal dependencies, downstream external dependencies. The internal upstream and downstream dependencies will appear in your project plans. You may also have your external upstream and downstream dependencies in the project plan, however, it is the external dependencies that will need to be called out separately in the RAID Log for monitoring.

Wait There is Still More to Come Next Episode

Next week we will delve into the following ways to put the RAID Log to work for you

  • How Do You Use a RAID Log
  • What Does Management Do with the RAID Log
  • How do you Incorporate a RAID Log Into a Project
  • How do you Maintain a RAID Log
  • How Quickly Should Items be Mitigated or Resolved


Photo Credit: Disco-Dan. “Fan Bay Deep Air Raid Shelter And Magazine Room.” Flickr. Yahoo!, 15 Feb. 2013. Web. 14 June 2015.

#149: Failure to Launch

failure to launchThis week on CIO Playbook with Jeffrey Hurley, I am Failure to Launch and how to overcome it. Failure to launch is the gap that is preventing you from achieving your dreams and desires. As you move forward in life there are roadblocks and diversions that take us away from our dreams. I want to give you a few ways to find your dreams again and return to the pursuit of them. Each of us is equipped to accomplish great things and overcoming the failure to launch will get us that much more closer to accomplishing our individual greatness.

Failure to Launch

Failure to launch is of defined as lacking the skills to accomplish what you want. Being out of sync with your peers or family members. Thus when someone is in the midst of a failure to launch they often find themselves seeking and avoiding the risk of failure. How are they doing this? By avoiding the consequences of their behaviors by choosing “not to behave”.

For this dialog I am going to use the following definition for failure to launch:

Deal with reality

Start with identifying your skill gaps that are preventing you from moving toward your dreams and aspirations. What capabilities do you have and what do you need to work on to get you to where you want to be.

Start with improving your presentation skills by joining Toastmasters International. This organization will allow you to practice your leadership and presentation skills in a risk free environment.

Then learn to manage your money. Set a budget and start saving funds. No matter where you are on the income scale you should be able to change your lifestyle and save money. It is impossible to go after your dreams if you can’t budget. Learn to plan by setting aside small sums of money each month to build a war chest for the future. this will involve learning to avoid instant gratification when the desire hits you.

Establish Yourself

Now that you have identified your skill gaps it is time to find ways to address them. Start by taking classes. This can be through your local university or via online course ware. These classes will give you a regular set of deadlines through the coursework that will enable you to build positive work habits. Another capability that will enable you to accomplish your goals.

Then start working on side projects. These side projects can be through your current job or via part-time work. I would suggest that you initially look into doing volunteer work for a local charity, volunteering in the area you are looking to improve your skills in. The nice thing about being a volunteer is you won’t get fired and because you are not being paid you can quit at anytime you decide to pursue another strategy.

These strategies will help you define your clear direction. Finding out where you want to go is what is another step toward beating failure to launch.

Address the Psychology

Talking anything new will create anxiety. It is in our nature to be cautious when exploring new things, this is part of our evolutionary make-up from a time when throwing caution to the wind often resulted in being eaten by a lion. Mild forms of anxiety are easy to address by taking action. However, greater forms of anxiety may require more effort and outside help.

Another challenge is the natural desire to procrastinate. We all procrastinate and the best way to overcome procrastination is through action. By just starting you will find that procrastination will fall away as you begin to get into the flow.

The most important skill to develop is “grit”. Grit is the consistent and persistent working toward your goals. Even in the face of discouragement it is vital that you keep moving forward. Everything worthwhile will have setbacks and bad days. Being able to overcome these and continue to make progress will spell the difference between failure to launch and achieving your desires.

Don’t be afraid of confrontation. Confrontation is very uncomfortable and I recognize this, however, many things we seek do require us to take the risk of confrontation. Now there is very few things in the modern world that stand between us and our goals that we should be afraid of. So, step into your fear and face it head on.

Set Incremental Goals

The best way to start moving in the direction of your dreams and objectives is to set small goals. Look at it as beginning a weight lifting regimen. Before you can lift heavy weights you have to start with lighter weights. The same goes for setting and achieving goals and developing your “grit” muscles.

Start by setting a simple saving goals. Put aside a few dollars every week into a savings account. This could be as simple as bringing your lunch to work and putting the equivalent of what you spent on lunch into your savings account each week. Set a goal to work out; again this could be as easy as setting aside time to get up from your desk and taking a walk around the office floor. Then building up from there

Take Time to Dream

One of the biggest challenges contributing to a failure to launch is the lack of a dream to provide the motivation. Set up a dream board somewhere in your home where you will see it every day. Populate the dream board with articles and pictures of things you want from homes, cars, vacations, hip clothing, and so on.

Get out and tour model homes and test drive cars to get a feeling of what you are after and what you plan to reward yourself with upon accomplishing your goals. Spend a few minutes each day with no electronic devices, giving your mind time to unwind. I would suggest getting up early and watching the sun rise. Begin to appreciate the things in your life and let the creative portion of your mind free. By doing this you can enable your “launch muscles’ and beat the failure to launch.

What’s Next

It is okay to be scared or uncertain about the future. Many people never really figure out what they want and wander through life guided by what happens to them rather than shaping their future with goals. Face life’s challenges head on and take action. You will discover who you are and what you can be. Overcome failure to launch and become happier and more successful.


Photo Credit: Jurvetson, Steve. “Rocket Firefall.” Flickr. Yahoo!, 3 Dec. 2011. Web. 7 June 2015.

#148: Asking for Funding

Asking for FundingThis week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project manager with some of the secrets to asking for funding of your organization or the project. Understanding how to ask for money and recognizing that it is very much a fund-raising activity is a very important component of the project delivery process. I suggested that managing a project portfolio is very similar to managing an investment portfolio; one of the primary activities in an investment portfolio is the process of raising funds. Once you have determined a project should be part of your portfolio you will then need to get the needed budget funding to begin the analysis and design work..

Avoid the Lecture and Present Solutions

Have a conversation and blend in the facts. Most of us know what it is like to be lectured to, thus it is best to avoid the perception of lecturing your audience; it will turn them against your ideas. We should be focusing on how to get our point across through the demonstration of understanding the business challenges the organization is facing and how technology will assist in solving the problem. As technology leaders we should be problem solvers and coming up with creative solutions to business challenges. If we wait for our business partners to come to us or to have a solution then you will end up losing the first mover advantages that could be reaped from adopting new technologies in your organization.

Be prepared to be challenged on what your assumptions are and what math you used to arrive at your conclusions. Healthy challenges to ideas is good, it will ensure that important risks can be avoided.

Be Straightforward and Transparent

We all know technology is expensive; business leaders, non-technology professionals, and technology professionals all know this. Thus we should not be afraid to discuss costs when we are seeking to provide a technology solution. Each audience is different, so picking the appropriate timing for sharing the cost of your projects is something that, as presenter, we need to discern. I have found that this can very day-to-day.

Be aware that even though technology is expensive, whenever “finance” asks for money back we seem to be able to find it. We are all aware that when we estimate our budget, it is usually months in advance of when we plan to spend it. Thus, things will change by the time we start spending money and it will most likely cost more than what we estimated. This is in direct conflict with our ability to give money from our budget back to “finance” when they are looking for cost savings. So how do you reconcile this dichotomy? This is a micro versus macro challenge and his hard to demonstrate easily. However, showing that individual projects make sense, yet when looked at across the whole portfolio individual issues get blended,

Demonstrate the Benefits

In episode #147 I discussed the building of a better business case. This point is where you will leverage the business case. Being able to demonstrate how spending money on technology will enable the future, drive revenue, or provide multiple key soft-dollar performance improvements will enable the business leadership team to make the best possible decisions on technology spend.

Avoid Fear Tactics

Many studies say that for personal decisions we are motivated by fear or by pleasure, however, fear tended to be a stronger motivator. I have found that while fear does create action it becomes tiresome and the decision-making team does not look forward to negative reinforcement. If you want to consistently gain support for your ideas and projects find ways to demonstrate the positive benefit they provide over fear-mongering.

Practice Beforehand

Practice, practice, practice. I can’t say it enough. Going in prepared is the most important thing you can do to get your projects and budgets funded. Having the necessary confidence comes from practice. Many of you will claim that you can “wing it” and do fine and I argue this will not produce your best performance. All sports teams practice, all actors practice, weddings even have rehearsals. Choosing not to practice is selling yourself short.


The best approach to getting the fund you need for your next project is to be transparent about the process of determining the costs, the benefits, and having a conversation with the business leadership teams. It is clear that most of our business leaders do not want to understand technology, they want their issues resolved they aren’t interested in the details of how you solve them. The reality of our situation as technology leaders is we have to demonstrate an understanding of our businesses we support, delivery to the current business need, while laying the strategic foundation for the future.


Photo Credit: Lake, Howard. “Funding.” Flickr. Yahoo!, 22 Aug. 2010. Web. 31 May 2015.

#147: Building a Better Business Case

building a better business caseThis week on CIO Playbook with Jeffrey Hurley, we discuss building a better business case for your programs and projects. One of the most important components of a project decision process is understanding what it will bring to your organization. I consistently press for managing your project portfolio like you would manage an investment portfolio. To determine if a project should be part of your portfolio you will need to have some form of metric to measure the opportunities you are facing. I am making the argument that building a better business case will give you a consistent metric for determining which projects get investment and which projects do not.

What makes a better business case? I believe it is going beyond just the ROI and payback period to understand the broader business implications. A business case should consist of the following items:

  1. Cost vs, benefit
    1. Three year projection
    2. Hurdle rate analysis
  2. Staffing plans
    1. Full time
    2. Contract
    3. Vendor/Integrator
  3. Location analysis
    1. High cost vs low-cost
    2. Billing allocation
  4. Soft dollar analysis
    1. Revenue preservation
    2. Risk reduction
    3. Sales performance
    4. Business effectiveness
    5. Operational effectiveness
    6. Technology effectiveness



Photo Credit: Library, MCAD. “Serious Business.” Flickr. Yahoo!, 27 Mar. 2010. Web. 31 May 2015.

#146: Why is Project Management Important

Why is Project Management ImportantThis week on CIO Playbook with Jeffrey Hurley, we discuss Why is project management important. According to David Allen in his book Getting Things Done,  we all have projects. However, the most common projects that we experience in our jobs tend to be technology projects. Even though most technology projects are actually business projects with a technology component.

Why is project management important? As leaders both of business and technology organizations we have responsibility for large budgets dedicated to increasing business value and ultimately the bottom line profitability of the organizations we work for. To accomplish these objectives we have to invest in improving the way we do work and at the same time capitalize on new opportunities.Project Management is about:

  1. Improving communication
  2. Increasing transparency
  3. Providing organization
  4. Defining resource needs
  5. Managing the details

Improving Communication

Earl Nightingale said, “Success is the progressive realization of a worthy goal or ideal”

Even with the modern advance of mobile phones, email, instant messenger, and so on inter organizational communication continues to be one of the most difficult challenges. Getting the right information to the right people at the right time is core to a project’s success. This goes beyond communicating to the project team and out to the stakeholders. Keeping everyone abreast of their responsibility and informed is the primary role the project manager plays in running a project.

Increasing Transparency

You could argue that increasing transparency is really just improved communication, however, I believe it to be such an important part of why we need good project management that I am calling it out separate. Projects generally have large numbers of staff, dollars, and equipment at work at any given time. The leaders of the organization who have the fiduciary responsibility to bring value to the organization at the best value often cannot spend the time needed to manage all of these assets. Thus it is important that they understand what, why, when, where, and how these assets are being deployed. Project management provides an avenue for understanding.

Providing Organization

I just said that they average project has large numbers of people, equipment, and dollars at work at any given time. Thus ensuring there is organization and planning brought to how these assets are deployed is a key tenet of project management. To ensure your organization is getting the best value from its assets means ensuring they are organized so as to be more effective.

Defining Resource Needs

People Resources

Every project needs people resources to get the work done. The project management process builds the understanding required for acquiring the necessary people resources.

Material Resources

Equipment whether it be machinery, supplies, software, hardware, etc. is used in the development of any project. Understanding these resource requirements early in the project process will ensure their availability when needed rather than delaying action while teams wait for the materials to arrive.

Financial Resources

Projects require funds to deploy the people and material. Finance is a key indicator of how a project is doing. From the funds defined at startup to the spending rate throughout financial resources should be carefully monitored.

Managing the Details

Overlooked details is the single largest reason projects fail. Learning to not take anything at face value and probe deeply until satisfied is core to realizing project success. It is human nature to procrastinate and therefore the project manager becomes the single source for avoiding project procrastination. The constant remainder of items and deliverables do the project manager sets the pace for the team to deliver.

Why is Project Management Important

Why is project management important? Because without effective project management communication, transparency, organization, resource needs, and the details can all get lost in the activity of the team. Project management helps to reduce the risk of project failure at the hands of disorganization.


Photo Credit: Veeneman, Angeline. “Clear about Your Options.” Flickr. Yahoo!, 11 Mar. 2014. Web. 17 May 2015.

CIO Playbook