Tag: Requirements

8 Things You Must do Better to Make Better Decisions

Written by Richard Lannon on December 20, 2016. Posted in Articles. 5 Comments on 8 Things You Must do Better to Make Better Decisions

I have been thinking lately about what it takes to make decisions. Just recently I was presented with a situation where some major decisions will need to be made.

Ones that impact changes in business and careers focus and could mean going into a whole new direction. So you have to make the best decision with the information at hand for your organization. From that perspective I think there are eight things you must do to make better decisions.

1. Invest in decision making skills.

This is something that holds true today as it did ten years ago or more. I see this as a foundational skill that people need to learn, practice and apply. There are many approaches or methodologies that can be applied in the decision making process whether you are a traditional organization, project based, a committee environment or driven by the board of directors. Often the fundamentals of decision making are missing. Look at the environment and create an appropriate decision making structure.

2. Create time to think ahead.

Time, time and more time is something we don’t have. It has become a luxury that most people can’t afford. Yet making good decisions requires time to reflect and look at the road ahead. What if you are considering changing careers and decide to go in a whole new direction? This is a big decision. This applies to a business venture also. Change and transformation are difficult to do on a whim, often you are required to think and plan ahead. But don’t over think long term plans as things change around you quickly.

3. Know who you serve.

This is an important point to answer. I know a lot of business leaders and professionals who I am completely confident in their ability to get the job done, to move forward and make things happen. But, they lack an important insight and clarity of who they serve. Decision making is a whole lot easier if you know who you serve whether it is a specific target market, an organization or something else. I think it provides opportunities to make mindful decisions and improve innovation and creativity in solving problems due to clarity and focus. It does not matter if you upset the market because you know who you serve.

4. Question everything, especially the business.

I often get asked how I would approach a specific problem. I am in a meeting and someone sets up a scenario and wants to know my approach. Any good business analyst, trainer or consultant will know the basics; define the problem, evaluation solutions, implement the approved solution, and measure the results. Part of the process is to question the business model. Recently I had this happen in a meeting with an executive director. I was presented with a question and responded but within that response I placed questions to better understand the business model of this organization.

Turns out they are looking for a change and the business model is suspect. It is always good to question, even when answering.

5. We can all think in a straight line.

Straight line or linear thinking is the a, b, c, of decision making. With so many organizations talking about innovation, creativity and being intentional I wonder what’s the point. There are many theories about what approach you should take. I still think the best approach to decision making and initiative integration is a mix between predictive and adaptive planning. These two approaches provide the best of both worlds, and when blended, often provide an organization an approach that works beyond the mere linear.

6. Create a story around decisions.

Life is a story and you write it yourself. With every decision there is a story that comes from people discussions, thinking, making assumptions, determining impact and communicating the decision. Wouldn’t it be great if you could create a decision narrative that is beyond the old boring business report? People want to be part of the decision story that makes a difference thus bridging organization gaps. You should create decision making stories.

7. We are all moving at the speed of a click.

Over decades my career has been part of the professional consulting and service economy which has accelerated at lightning speed in recent years. When I look at the professions’ value stream I think we need to make better decisions around the downstream business environment. Clients no longer just order or buy stuff they engage now in a very different way where it becomes difficult to determine the ROI on business activities. Margins wither as the need to provide valuable free content increases making business decisions a challenge to make. No matter the business you are in, the accelerated service economy is impacting your business.

8. Find a tool, reduce your risk and get costs under control.

The strategic business analyst looks at the past, present and future of a strategic plan and approach and use financial analysis of NPV, IRR and ROI within your business case. But it is important to go further and look at risk with uncertainty analysis. This is something that I learned over time from various economic adjustments (ie: dot com bubble burst, corporate and accounting scandals, subprime mortgages issue, and resource industry collapse) I think uncertainty needs to be determined better. Business intelligence and uncertainty reducing tools can be used to assist in this analysis. My point, the business analyst can play an important part in helping organizations make decisions through embracing uncertainty analysis approaches and tools to help deal effectively with unpredictable times.

Final Thoughts

Big decisions are tough to make, especially when you have invested so much time and effort on your business or focus area. When you work in a space where you are building skills and helping businesses define their future, you start to realize that there are certain truths that exist. One truth, everybody wants to survive and be around a long time. The second truth, that there is always a purpose that needs to be achieved. Third truth, good decisions and core competencies take you a long way to creating a profitable future thus achieving the first two truths.

OUTSIDE THE BOX FORUM: Small is Better

Written by Robert Wysocki on December 13, 2016. Posted in Articles. 4 Comments on OUTSIDE THE BOX FORUM: Small is Better

Complex and uncertain projects are more likely to succeed when scope is minimal. There are lots of reasons for this observation.

Too Many Unknown Unknowns Lack of clarity in the goal and or solution results in a discovery process that cannot be predicted. If the project is dominated by unknowns, there are approaches (i.e., prototyping) that can identify feasible directions to pursue in the search for acceptable solution components. The most important approach is not to guess and proceed on unsubstantiated guesses.

Start From the Knowns In the complex project space we do not guess. We start with what is known for certain about the goal and the solution and build on that for further definition of goal and solution. That speaks of small steps and risk containment.

Probing for Details The ECPM Framework introduces Probative Swim Lanes as an aid for goal and solution discovery. These a short, low cost probes into possible solution components. If any prove to be feasible directions, further investments can be made until the direction proves fruitful or should be abandoned.

Top 7 Reasons for Project Failures

Written by Brad Egeland on November 7, 2016. Posted in Articles. 7 Comments on Top 7 Reasons for Project Failures

We all know that more projects fail – in some way or another and to some degree or another – than succeed.

But what causes those failures? Perhaps a better insight into the root causes will help us to avoid or mitigate some of those failures as we are attempting to deliver on our project engagements.

I decided to take an impromptu survey of business analyst and project manager colleagues, and connections as well as CIOs, CEOs, creative directors and PMO directors, and CTOs to see what they thought were the top causes of project failures. I received a little over 150 responses – a good sampling – and created a top 7 from those enlightening responses.

1. The project has gone over budget.

Too common, very painful. I always say, a 10% budget overage is usually acceptable and if not, can probably be fixed over a relatively brief period of time. However, a 50% overage will almost always be disastrous, will likely never be acceptable, and probably can never be fixed. At least I’ve never been able to fix one that is that far off the mark. The key is to stay on top of the project budget on a weekly basis. Weekly review, analysis, and re-forecasting of the project budget will help the business analyst and project manager to keep the budget manageable and will mean those in charge of the project financials are never surprised by a project budget that has gone off the mark by 50%. They will realize there is a problem in time to take proper corrective action.

2. The project is too far off the timeline.

The next most common problem – the project has gone too far off schedule. So many variables can cause this one…work that wasn’t planned but can really be assigned to a change order, gold-plating of the solution, poorly estimated work efforts, a project delivery team that is lacking the right skills to get the work done on time…the reasons for missing the schedule could be nearly endless. What do you do to get it back on track? If it’s realized too late or corrective action doesn’t happen at the first sign of a scheduling problem, then there likely isn’t really anything that can be done. You keep moving forward because you have to…but you’ll never get the the project back on the proper timeline.

3. Requirements were poorly defined.

Requirements are the lifeblood of the project. Good requirements are the basis for estimating and pricing, building the schedule out, building the right solution for the customer, recognizing when change orders need to happen, properly testing out the solution, and rolling out the right solution to the customer’s end user base. If requirements are poorly defined, then any or all of these could miss the mark. When that happens, the project will experience many issues, possibly a decent amount of expensive re-work.

4. The customer was not ready to start.

Sometimes the customer just isn’t prepared to start. I had this happen once when my business analyst and I were working on requirements definition with the customer. They weren’t ready because they didn’t understand enough about the potential solution to connect the dots with us on their business processes and how they translated into real project requirements and a functional design. I had to halt the project and line up some customer training. Likewise, sometimes the customer says they are ready, but they still have some project defining left to do on their side or possibly even some issues completely unrelated to the project at hand that are getting in the way and have to be taken care of first. I’ve had that happen many times in my consulting practice with clients I’m working with. The end result is time and effort and budget wasted on work that basically gets erased, leaving the project a mess when the work is restarted.

5. Delivery team did not have the right resources.

When the project is started with the wrong team in place, it can be extremely painful. You didn’t realize you needed a database guru with ‘x’ skill set or experience. Now the project has started, and you need that experience ASAP. What are you going to do? The project and project timeline suffer as a result. And onboarding project resources later in the project that do have the right experience or skill set can be expensive.

The best situation is never to start the project without the right team ready to go, but that can’t always be the case because you may not realize you don’t have the right team till the project is well underway.

6. Inaccurate estimating of the work to be performed.

This can be a common issue. Often, initial estimating is performed by an account manager or technical sales person, and that often leaves the project manager, business analyst and tech lead in the position of making that original estimate work because it was the basis for pricing the effort. You can’t write change orders if the effort hasn’t changed. The end result is a project that goes off budget if the work is performed as planned but there aren’t enough hours and dollars in the project to cover it. Hence, a project failure.

7. The project did not have proper support of the organization.

Any project undertaking that lacks support at the top of the organization is unlikely to remain viable for long. Funding and staffing will be an issue, and client confidence will suffer as well if they become aware that the project does not have the support of the delivery organization. Reasons for this could be a realization that the project does not align well with the delivery organization’s core competencies or possibly the direction the are planning for future project engagements. Either way or for whatever reason, the project is likely doomed.

Summary / call for input

This is my top seven reasons for project failures as gathered from BA, PM and related project colleagues around the world. What are your top reasons? What would you change on this list or add to it? Please share your own experiences and discuss.

5 Reasons Why Some Projects are Harder Than Others

Written by Brad Egeland on June 7, 2016. Posted in Articles. 3 Comments on 5 Reasons Why Some Projects are Harder Than Others

As I’ve always said, no two projects are the same and all projects are not created equal.

While those are definitely not profound words, we still get perplexed sometimes as to why one project may seem so much harder than all the others. Why do some projects we are managing seem to go off without a hitch (that’s just a perception – they all have hitches), and then others can leave us struggling so much we come out the other side thinking “I am never going to go through this again”?

My take – from experience, observation and logic – has narrowed it down to five common problems that can make one project stand out from the others in terms of difficulty and issues experienced when all else seems to be about equal.

Please be thinking about your own experiences and reasons as you read these and feel from to share and discuss at the end. Here are my reasons:

1. Different level of complexity

While we think a given project was about the same as other similar projects we have managed or are managing, we eventually find out there was an underlying complexity to the current project that caught us off guard, made it stand out in terms of issues, pain and suffering. Often times when we find this out after the fact, we are faced with rework, missed deadlines, over budget issues, and customer frustrations that only add to the pain and suffering.

Usually this is related to requirements, but it may also be a product of not accurately or fully assessing the project client’s environment and the eventual integration that will be required as part of the project.

2. The unknowns outweigh the knowns

We may not immediately realize this – which can get us into a mess quickly – but the unknowns on the project may actually outweigh the knowns. In short – don’t start until you eliminate as many unknowns as possible!

Very early on – during project kickoff preferably – discuss assumptions and unknowns with the project client. Do they know their environment well enough to move forward? Do they know the real need well enough to move forward? Have they truly identified the real need? Do they understand the impact to the rest of their organization to move forward with the project and the proposed solution? If not, then the implementation phase is going to surprise you and everyone else and likely be very, very painful. You may satisfy one group of end users, and completely stop another group in their tracks who were not intended to be affected at all.

Seriously, if the project client comes in with more questions than answers, you may need to double or triple your planning phase time and budget, or you will live to regret it.

3. The customer is disengaged

While it may seem like a customer who isn’t around to ask questions and slow your team down during a technical project is a blessing, the exact opposite is, in fact, true.

You need the customer to be engaged. You need them available to answer questions, clarify requirements when you hit a questionable area, explain a business process you don’t quite understand, and take care of the project tasks that you have assigned to them.

Yes, many project sponsors have lots of responsibilities other than the project you are managing for them, but you need them available so that key decisions can be made and the project can stay on time and on budget.

4. The project team is in flux

When your project team is changing or being slowed down by other project responsibilities, team members may have it can cause major issues on a complex project that needs their attention and focus now.

Taking drastic action to replace distracted or overloaded resources is the last thing you want to do as it can be costly and time-consuming. If your team seems to be experiencing issues like this or internal conflicts, try to recognize it as early as possible and be proactive rather than reactive in fixing the problem. The longer you “wait and see if it will fix itself”, the more problems you will have. Rarely does it just fix itself. Rarely does anything just fix itself.

5. Project requirements lack the necessary detail

Project requirements are the lifeblood of the project engagement. They must be complete. They must be detailed. They must be understandable. And it would be nice if they were accurate. Poor requirements result in rework, scope creep, questionable change orders (whose fault is it, who should be responsible, who should pay?), and missed deadlines. It’s a difficult call especially at the euphoric beginning of a big project, but if the requirements are questionable, and you feel there needs to be more detail and work put into them, don’t move forward. Go back to the drawing board. Requirements are the basis for functional design, technical design, user acceptance testing, and ultimately project approval and sign off. If you don’t have it right at the beginning of the project, the rest of the project can be in question.

Summary / call for input

In reality, there can be about a million reason why one project is much harder to manage and control than another. What I’ve presented here are just five of the more common ones that can negatively impact just about any project in any industry.

It takes a confident, detail-oriented project manager to watch out for these, to halt the project when it needs to be stopped and assessed and to make the quick decisions and tough calls to get it back on track. The indecisive project manager may let the project proceed without stopping and taking proactive action leaving the project limping forward while hoping it will get better in the next phase. It won’t! You’re left with a project that ends up being more difficult than the others and more difficult than it needed to be.

What about our readers? What comes to mind as to reasons why some projects you’ve managed have been harder than others when the project may have seemed to be about the same as others you’ve taken on? What can turn the tables? Please share your thoughts and experiences.

An Expensive Leap: How Jumping to a Solution Cost Billions and Made the Problem Worse.

Written by Elizabeth Larson on May 23, 2016. Posted in Articles. 4 Comments on An Expensive Leap: How Jumping to a Solution Cost Billions and Made the Problem Worse.

How would you solve this problem?

The US VA has unacceptable wait times for veterans seeking medical assistance. The VA medical centers around the country are overbooked and understaffed. Some veterans have to wait months for appointments and treatment. There has been negative media attention on this growing problem, especially when it came to light that VA administrators covered up the delays by fabricating reports. Other branches of government, like the Congress as well as the public, are up in arms.
What do you do to solve this? Well, the US Congress solved it by allocating $10B USD to allow vets to seek care at private medical providers through a new program called Veterans Choice. On the surface, this seemed like a reasonable solution since it quickly expanded the potential providers who could serve the vets. Oh, did we mention that Congress gave the VA 90 days to pull this program together?

Related Article: Decision Making: A Critical Success Factor

That sounds like a recipe for disaster. Can you image any project you might work on that has a $10B budget in the first place? Let alone 90 days to conceive, plan, and implement it? Most things in the government take 90 days just for the conception part much less the whole thing.

Well, as you can probably guess, the program is having trouble. Billions have been spent, and the problem has gotten worse. According to NPR, the wait times for veterans has actually increased with the privatization plan. See www.npr.org/2016/05/17/478215589/how-congress-and-the-va-left-many-veterans-without-a-choice for details on how the level of service has gotten worse instead of better. Obviously, organizations want projects and programs to meet their goals and objectives and improve their KPIs( Key Performance Indicators) and not to make them worse.

There are several reasons for this colossal failure, and we invite you to read the story to hear about them if interested. What we’d like to explore here are some lessons learned (or at least observed from afar) about this whole affair:

Jumping to solutions. Resist the temptation to jump to solutions. Most problems will have multiple solutions that can fix the problem. However, some are almost always more practical, will cost less, and cause less disruption than others. Picking one solution without analyzing the problem for root causes, without looking at the feasibility of implementing each, and without understanding both the costs and benefits of the solution will more than likely result in wasting money and a great deal of rework. For example, the use of private physicians meant that some veterans would have to travel much further to receive care under the new solution. Over 28,000 of them were affected in this way, a significant number.
Politics. Remove politics from your initiatives if possible. With the VA and the US Congress, that is like asking a cat to remove its whiskers. It is simply not going to happen. But in business, surely we can work as neutral facilitators to reduce the political and the biased views of stakeholders when addressing the problem at hand.
Resources. The Veterans Administration was tasked with creating this new program when they were already underfunded, understaffed, and overly extended. So they had to outsource the program’s creation. Out of 57 potential vendors, only four were willing to attempt the near-impossible task of building a major infrastructure so quickly. Then two of the companies backed out when they learned it had to be finished in 90 days. On our projects at work, we need to be sure that we have a plan to implement the changes and that we have some idea of the resources (people, time, and money) to complete the work.
Ah, the problem. How many of you think the trouble started when Congress ignored the real problem? Raise your hand, please. If anyone involved with this initiative had done any root cause analysis, they may have discovered what it would take to really fix the problem. If the urgency had been less, perhaps they would have realized that delays in scheduling appointments were in large part caused by the VA’s reliance on paper files. The proposed solution of privatizing the care did nothing to solve the paperwork problem. Here, as in our organizations, it often seems like we have a solution chasing a problem, in this the case reducing federal programs in favor of outsourcing. Analyzing both the problem and the solution would have led to better outcomes.
Cobbling a Solution. Because of the tight time constraints and few vendors, the solution was built on top of an existing vendor system. That may have been OK if the existing system was effective, but it had a special-purpose focus and had several flaws in it. Adding a “quick-and-dirty” extension onto an already faulty system is obviously never a good idea.
Scope. We can all applaud the allocation of the $10B to address a major problem. The difficulty with rushing something so large in so small a timeframe is that it never works.
- Chunking the effort, say by piloting it in a few VA Centers, might have quickly uncovered issues that could have been fixed before rolling it out system-wide. It may have also revealed that the solution was unworkable before further money was wasted.
- Allocating some of the appropriation to increasing staff at existing VA centers would most certainly have helped. (Full disclosure: our son is a physician at the Portland VA. We have heard firsthand that his Center needs more staff at all levels, so we assume every VA may be in the same boat).
- Some of the funding could have been devoted to converting the VA’s antiquated paper records to electronic medical records. It’s not hard to see that would have helped in reducing delays.
Business Transformation. A huge new program like Veterans Choice represents a major shift for all stakeholders, especially the veterans and the medical providers. Rushing a major change in so short a time minimizes the need to transition stakeholders to the new solution. NPR mentions “many veterans were confused” by the new procedures, caused in part because the Choice program had to interface with the overall VA medical system. The interface was resolved by adding a 3rd party administrator between VA doctors and the outside physicians. The result complicated scheduling and made it worse. With so little time to adopt the new program, training, communication, and publicity were drastically abbreviated.

In summary, the way the Veterans Choice program was handled left much room for improvement. The VA is reconsidering how much of the administrative outsourcing they should have done. Congress may not allow them to do that. The problem first came to light because of scandals in covering up the delays and Congress is considering expanding the Choice program to take more control out of the hands of the VA. Meanwhile, the rework and delays continue.

About the Authors

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.