Energizing Flailing Projects

Business analysis is all about detail – the right kinds of detail at the right time. The problem with new projects, especially large ones, is they tend to “flail’, spinning wheels in unnecessary directions as they struggle to gain momentum. Here are some tips and traps to stop the flailing.

Remember

New project concepts seldom have lots of resources on tap, just sitting there waiting to be spent or deployed. Reality dictates that a thin process be used – something that consumes relatively few resources, but takes the project a giant leap forward. Here’s a tip on getting a larger project off the ground successfully: think of ‘start a new project’ as if it were a process (mainly because it is!). Like any process, it has to have five key ingredients: a trigger, an outcome (i.e., building positive momentum), some set of activities people agree are valuable to perform, some set of stakeholders impacted by the process, and enabling resources supporting the process. Keep it simple… if any of these five ingredients are missing a process falls apart (i.e., your project begins to lose momentum).

Many people don’t have a clear image in their mind of what success is when it comes to initiating a project. There are often too many variables, so when you’re in the thick of it, all you’ll have is a general sense of the project building positive momentum, or a feeling that momentum is waning, as unsuccessful tactics consume resources in unconstructive activities. Focus on ‘firming up’ your five ingredients to a process and you’ll feel momentum systematically build.

Here’s how

Business systems are also all about business process. Identify the basic business process areas affected by a new system and start looking at the high level scenarios for each of these processes. Ask how complex each step in a process scenario is, and how well known and documented these processes are, and ask if it is likely that the new business system will impact a particular step in a scenario heavily, moderately or lightly. Then, look at how these basic process building blocks need to share information with outside systems or processes in order for them to function properly. Keep the scenario building for each process high level, once someone uses the words “that depends” when they are describing their high level scenario – you’ve gone far enough. At this point it’s only nice to know how many different variations need to be looked at, it’s not absolutely essential to have documented them.

In this simple set of above steps – what is happening in the five key ingredient areas?

• Scope. You’ve quickly identified the magnitude of analysis work (number of processes, number of use cases, complexity of these use cases)
• Stakeholders. You’ve identified the stakeholders (who interacts with the process in conducting the activity or as a user or supplier of information to the process)
• Activities. You will frame up a plan of action (once you know the use cases, you specify the plan for detailing each of these) so you know the steps that need to be taken to get requirements fleshed out.
• Resources. You can then estimate the amount of effort needed to complete the analysis of the business processes so you know how much resource is expected from stakeholders. You can do this because you know the number of use cases (approximately), and know how long each stakeholder has to be involved.
• Trigger. Once you get agreement to the requirements definition plan from the business and technology, including agreement from the business and technology to provide specific resources to participate in specific ways to complete the plan.

Once agreement happens, you have a project!

Compare this listing to the five ingredients. Does the above sound like a decent process for kick starting a new project?

The business analyst trap, in initiating projects, is to get caught up in complexity. Some of you will recognize my recommended approach as a requirements planning process – it’s fast, efficient, and can be used to energize projects that are flailing. The only problem is… very few people do it. Requirements planning is not about simply filling in another template; requirements planning is about gaining significant momentum on larger projects very quickly.

Don’t forget to leave your comments below

---

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.