Category: Consulting Strategies

  • Setting Expectations and Project Success – Three Easy Steps for Improvement

    Setting Expectations and Project Success – Three Easy Steps for Improvement

    We all can use more ways to achieve project success or at least increase its likelihood.  Of course, there are many steps we can take in this effort.  However, few provide the impact of setting expectations and managing them throughout the process.  Here are some ways to help you do precisely that in your next project.

    Concrete Over Vision

    The most significant variance in expectations in my experience comes down to vision.  The end product you envision is not what your customer sees.  Since both of these visions are in someone’s head, we need to get those out and compare notes.  Guessing and assumptions are prime culprits in expectations that are out of sync.

    This is why prototypes, wireframes, and user stories are so important in project success.  These tools give us a way to put down on paper the vision in our heads and resolve any differences.  It can seem redundant to write down something all parties appear to agree on, but that does help avoid assumptions and other communication issues.  I have found that we do not always have the clarification of communication that we think we do.  Putting thought into concrete form helps to alleviate that weakness.

    The Devil in the Details

    I once heard it suggested that software architects get in the habit of asking “and then what?”  This is an excellent approach to drilling down to the required level of detail for setting expectations.  The step to put our vision in a concrete form can lead us to think we have more detail than we do.  I have come across far too many customers that point to a page or application and say that is what they want.  However, as we dig into that example, we find that there are features they want that are not on the screen or assumptions made that are not stated.

    An example of this sort of error is easily seen in the assumptions about how a page works.  There will be menu items and other controls that imply action.  When the result is not adequately shown and defined, then it can lead to mismatched expectations.  The “make it look like this” is a good start.  However, it is only a start.  This starting point needs to be followed up with questions to clarify how every piece of the screen works.  This includes menu items, buttons, tab orders, notifications, validations, and more.  A picture is worth a thousand words and may also hide a thousand function points.

    Avoid Drift

    The third item we need to address is potential drift from our starting point.  A well thought out and thorough design up front can help us set and maintain expectations.  Nevertheless, there are surprises and holes that become apparent in any implementation that can impact that initial design.  These bumps can cause drift and even derail the direction that implementation is headed in.

    This problem is easily solved with regular meetings and updates.  Progress and bumps are addressed in each session along with discussions of variance from the original design.  The end product of this process is that expectations are “tweaked” along the way in concert with design adjustments.  Although there are other reasons to take this approach, I think managing expectations provides the most substantial payoff.

    There are thousands (or more) variables that go into project success.  Fortunately, a lot of what determines that success is how the solution is perceived.  Therefore, the better we are at setting and managing expectations the more likely our odds of success.

  • Incremental vs. All-in Change and Enhancement Strategies

    Incremental vs. All-in Change and Enhancement Strategies

    Sooner or later we have to consider how to change our systems.  This situation can come from growth in business, changes in technology (or requirements), or systems that have aged poorly.  When we reach the point of deciding on a move we often have to decide on the incremental vs. all-in approach to achieve our goal.  There are times when one choice or the other is obvious.  However, I have found that we almost always have both of these options available.  So let’s look at the risks and rewards commonly available to each decision.

    An Incremental Approach

    I find this option to be the most popular.  In fact, you might be able to rattle off some rewards and a few risks faster than it takes to read this article.  Nevertheless, it is helpful to go through the exercise and maybe a few items from either list will be new to your experience.

    Pros

    • The Risk is Reduced: Less change and more options to bail out or adapt.
    • Less Time Before Starting: Smaller changes can allow for less upfront planning.
    • Time To Bake In: Users have small changes to learn rather than large ones.
    • Less to Consider: Small scope of changes means less to worry about with each change cycle.
    • Easier to Budget: Tighter range of change and time frames make it easier to budget for changes and cash flow the project.
    • Avoid Re-inventing the Wheel: This approach allows pieces of the original system to survive and remain untouched.  Thus, business rules and proven validations do not have to be re-created.

    Cons

    • Total Cost is Higher: Overhead for each cycle adds up.  Therefore, more testing, deployment, and other phases will be repeated for each incremental change.
    • Longer Schedule: Much like the above item, the time to be done with changes is going to further in the future with an incremental approach.
    • Legacy Decisions/Constraints of the System: An incremental approach will always be tied to the original system in some way.  It does not allow for a fresh start or utterly new thinking.
    • System Stability: Regular change can make the system appear unstable to users and might be the reality as repeated touching of the core system offers opportunities for simple mistakes and human error to degrade the system.
    • Integrate Changes: No system is static.  Changes are required for a variety of reasons, and an incremental approach does not allow us to ignore change requests.  Extra effort is needed to manage change requirements and fixes along with the new/improved features being implemented.

    An All-In Approach

    This is a more courageous decision in almost every case.  In fact, this approach often results (directly or indirectly) as one that makes or breaks a job (or career).  The rewards are higher when this is correctly executed as there is more freedom to make huge strides.  That said, there is a lot to worry about as well.  Here are some of the pros and cons of this decision.

    Pros

    • Total Cost is Lower: A significant change requires a lot of testing and deployment work.  However, it amounts to fewer cycles and general overhead than an incremental approach.
    • Freedom to Innovate: The lack of ties to a legacy system allows us to learn from past successes while avoiding past mistakes. Substantial and meaningful changes can be made in this effort.
    • Shorter Time to Completion: There is not a need to run in serial as is needed in the incremental approach.  Resources can be poured into the all-in solution.  Thus, progress can be made in parallel with the current systems continuing to run.
    • More Stability For Users: This approach will result in a significant change when it goes live.  However, other than that point in time, the users will experience a stable and reliable system.
    • Less Elegant Utilities: A one-time step of significant change means the tools and utilities to do so only need to work once.  This is the opposite of the design required to make the same tools work when you know there will be multiple, smaller, executions of them.

    Cons

    • The Risk is Higher: When you make a significant change and choose wrong, it can result in a crippling loss to the company.  This can have productivity and financial repercussions.
    • More Time Before Starting: Planning and design are needed for the entire system to properly execute the all-in approach.  Every little detail needs to be addressed to reduce the risk of a complete failure.
    • More significant and Impactful Change: The substantial change of an all-in approach is hard to hide.  Often it will require training for the users to help them utilize the new system.  Alterations of business rules and procedures are often part of the content for deploying this solution.
    • Total Review and Design: The broad scope of changes require the entire system to be reviewed and understood.
    • Large Budget: A substantial project like this is harder to estimate and often includes more funding in a short period.  Incremental allows us to stretch out costs.
    • Re-inventing the Wheel: Often this approach requires core functionality to be rebuilt or re-coded and tested again.  This amounts to re-inventing the wheel for business rules and other functions.

    As you can see, there is a lot to consider with either approach.  The pros and cons balance out more often than we think they do.  Therefore, it is worth it to leave both options on the table on at least a periodic basis.  This will ensure we avoid knee-jerk reactions to one approach or the other.  As always, the more we know, the more we consider, the higher the likelihood of a successful decision.

    Going Deeper

    Incremental Changes

    When you look at the pros and cons of this approach, there are some essential assumptions made.  If you take a path that does not follow the premises, then the pros and cons will differ.  The “time before starting” and “less to consider” pros, in particular, are impacted by your approach to design. The assumption for incremental changes is that you will plan and design as you go.  This may not be the case.  Some organizations prefer to create and plan out their entire series of changes up front.  While this is a good approach, there are also valid reasons to hold off on a complete design when you are not sure far you want to progress.

    Similarly, the time to bake in and system stability items may vary in your experience.  There are ways to drag out an incremental approach so that the users do not experience noticeable changes.  Instead, they see undergo the changes as occasional enhancements.  However, this approach can significantly increase the time to completion and may increase the limits to what can be done (due to ties to the current system).

    Finally, let’s look at the re-inventing the wheel item.  An incremental approach can do this as well.  Typically, an organization will avoid touching the things that “work.”  The argument is that there is no reason to put effort into fixing something that is not broken.  On the other hand, when a core functionality can be improved, then it may be worth taking on that change at some point.  There is also the side effect that can occur where a core and stable piece of functionality is changed or even broken through changing other areas of the application.

    All-In Advances

    It should be clear that the all-in approach, in this case, is deploying all the changes in virtually a single push to production.  This can be a large number of changes to an existing solution, replacing one with another system, or starting from scratch.  Each of these three options has a very different set of pros and cons along with those mentioned.

    An important note about the all-in approach is that the sunk-cost fallacy should always be avoided.  There are many cases where companies dismiss an all-in change because they start with the idea of value for the existing solution.  Yes, there is knowledge and expertise and even momentum that the current system has.  However, if those aspects are all driving you over a cliff then how valuable are they?  Along with this, technology is always changing.  The options we had a few years ago are not the same today.  There are new solutions and standards available that might bring overwhelming value to an original or from-scratch system.  It is easy to stay with the momentum we have, but sometimes all that provides us with is false confidence.

    Final Thought

    The bottom line in considering the pros and cons of these approaches is that your mileage may vary.  In order to make these aspects real some intentionality is required.  For example, if you want to reduce risk through an incremental approach to change, then each step needs to be examined thoroughly.  This examination includes looking for potential side effects and downstream impact.  None of these pros or cons are automatic, and the right approach can highlight the pros while reducing the cons.

  • Creating an Effective RFP

    Creating an Effective RFP

    Sooner or later we all need to solicit proposals that provide solutions to a problem.  This might be a request for an application, a service, or products.  It should come as no surprise that an effective RFP process accurately defines the problem.  However, there is more detail that makes up an effective RFP.

    What is a Well Defined Problem?

    The challenge of a technical RFP is often the language required to create one.  The technical staff provide input (or possibly the entire response) to an RFP, so it is essential to communicate to them directly.  Miscommunication can make responses invalid or worse.  However, the writers of the RFP are usually on the business side of the equation.  This is not an insurmountable issue.  It just requires attention to the details that matter to an IT solution.

    The key is in the details.  A problem definition needs to include these pieces to provide the context required for a solution rather than just an answer to a question.  For example, an RFP that defines the problem as a need for a website with a “contact us” form is overly simple.  There is no context for a useful solution.  Think about how the details below can help respondents craft a more meaningful response.

    • Who are the primary users?
    • When will it be used? (business hours, 24/7, etc.)
    • What is the expected response time for the pages/functions?
    • Are there constraints or limits to the technology of the solution?
    • Will it have to scale? To what level?
    • How soon is the solution needed?
    • What sort of budget do you have?
    • What kind of company are you?  (line of business, employees, sales)

    These details may seem like providing too much information.  Nevertheless, these provide context for the solution.  These details will help the providers craft a solution that meets your needs.

    Know The Respondents

    As part of your RFP, you want to make sure you have the right people for the job.  A good RFP document provides a lot of detail about your company so it is only fair to request details about the respondents as well.  In a similar sense to the problem details, a good RFP requests several facts from the respondents.

    • How long have you been in business?
    • What does your typical customer look like? (size, business, focus, etc.)
    • Have any major changes to the company structure occurred recently? (merger, acquisition, etc.)
    • What sort of support staff do they have?
    • What certifications, audits, and assessments have been done on the company?
    • Can you provide some good references?  For example, customers that were provided a similar solution?
    • Describe the processes you use to ensure quality.

    An Effective RFP Takes Time

    Do not underestimate the value of your problem.  If you have a strong enough desire for a solution to search for proposals, then make it worthwhile.  Spend the time to properly detail your problem and allow for respondents to take their time in crafting a response.  I hope these items have helped you create an RFP process that works for you and finds a perfect response.