Tag Archives: project management

The 3 R’s For Courageous Business Analysis and Project Management

As the Enterprise Business Architecture Practice Lead at IAG, I attended the recent Business Analyst World event this June with extreme interest. The Business Analysis industry continues to grow – with more companies hiring, and more employees getting trained and certified than ever before. However, with that is a changing and dynamic environment as BAs are barraged by new methodologies from the Agile and Lean worlds; new and more prevalent ALM and requirements authoring and management tools; role confusion with BPM, Business and Enterprise Architects; and the continued pressure from their business, project management and IT colleagues.

This theme resonated throughout the conference as the subtext of many of the talks and workshops during the week.  As I sat at round tables and seminars listening to topics like the value and career path of the BA, Business Analysts were definitely vocal. I heard one participant say, “Between Management and PMs, I can’t do the job I was hired to do. Whether it’s by cutting my time short – or not getting access to the right people, I know I am not doing the job properly and it’s making me cringe handing off **** to the development team.” The frustration was clear. More than ever, they want to be value add players in the game. A game they feel is rigged against them.

Then there were the stats quoted all week long:

  • 68% of projects fail due to poor requirements (from the often quoted Chaos Report)
  • 45% of features put into production are unused (also from the Standish Group)
  • 40-50% of budget is consumed by rework (Boehm and Basili)
  • 75-85% root cause of rework is from poor requirements (from Dean Leffingwell)

Ouch. To the BA’s at the conference, this was taken as a personal attack. These stats used to be quoted to management to reinforce the importance of needing good requirements. To an audience of BA’s, this is now (quite falsely in my opinion) coming across more like a condemnation of poor work. I don’t truly believe that BA’s are perceived as the bane of every failed technology project, but it had that feeling.  And what made this even stranger was the feeling that they are being locked out of Agile projects – but still being generally accountable for solutions meeting the business needs.

With 6.2 trillion dollars being spent globally on technology projects what does this mean for the Business Analyst? Given the cost of substandard requirements, which according to the BA Benchmark could be north of two trillion dollars, the business case for the Business Analyst should be obvious. To support this, the DOL and one leading staffing firm predict a shortage of BA’s in 2013 and continued shortfall in supply as technology needs ramp up into 2020.

From the seminars I attended at the Business Analyst and Project Management World conference, one concept struck a chord for me – as advice for the Business Analyst and Project Manager – and a critical factor for application development success:

Have the courage to do the right thing.

Given whatever your role and responsibility is, have the confidence to do or say what you think is right even when others disagree.  Confronted with challenges and obstacles from peers and other stakeholders, stand resolute. Faced with uncertainly and confusion in your responsibilities in an Agile environment, create your value. Take responsibility. Learn and adapt. And stand by your convictions that good requirements and analysis are absolute.

Three R’s

As BAs and PMs, get the right information, the right training and right tools.

As Managers, help enable Business Analysts and PMs to do their job. Give them the right information, the right training and the right tools to do a good job.

For Business Analysts, remember these 3 R’s as your value add:

  1. The Right Plan: Work to a requirements management plan that defines the right approach, milestones, deliverables, tools, techniques and work plan.
  2. The Right methodology. Be adaptive and fit for purpose – ensuring the approach is appropriate, utilizes best practice and the principles of good requirements, analysis and architecture are maintained.
  3. The Right Requirements. Ensured by verification, validation, prioritization, review and traceability best practices.

And for Project Managers, the Right Stuff entails:

  1. Right alignment. All stakeholders agreeing on objectives, scope, requirements and solution
  2. Right resources. For all activities, but especially utilizing the right SMEs at the right levels that can provide expertise and decisions
    1. A strategy guy for the high level
    2. Control person for oversight
    3. And an execution person for process
    4. Right time frame. In the case of the initiation and planning phases, that there is enough time to do these critical phases just right.

Doing the right thing is hard. Doing the wrong thing is easy.

Have the courage to do the “right thing”!  Positioned in the “right way” to do the “right job”

– Judith Oja-Gillam

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Four Trips to Midnight

Midnight is a dark time, like a looming deadline which you’re pretty sure you can’t meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night – and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it’s a different problem altogether.

I’ve noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements – and that was just her personal time… not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night – hopefully some of these will prevent you from burning the midnight oil on your next project.

Continue reading

The Requirements Maturity Model Explained

The Requirements Maturity Model (RMM) is a means to benchmark an organization’s effectiveness in requirements definition and management by looking at maturity in six underlying capabilities. Like similar standards-based models, it classifies companies based on observed, tangible competency in each capability to make an objective assessment of overall maturity.

How is the Requirements Maturity Model Structured?

IAG’s Requirements Maturity Model has two dimensions:

Maturity Level: IAG’s is a staged maturity model similar to those used by several industry standards bodies. An organization progresses up the ladder (to the right) as goals are achieved and thresholds surpassed. Each level of maturity shifts the emphasis to different requirement practice characteristics. Each level builds a foundation for succeeding levels.

Capability Area: Six capability areas are assessed and combined to determine the maturity level of a organization’s requirements management practice. These six are the fundamental building blocks for requirements definition and management and include:

 
  • Process: Definition, usage, and management of requirement procedures.
  • Practices & Techniques: Definition of how analysts will perform work, the efficiency and effectiveness of these activities.
  • Technology: Provision, usage, and integration of software tools in the context of the requirements practice.
  • Staff Competency: Level of knowledge, skills, and ability of the workforce.
  • Deliverables: Definition, production, and usage of work products as output from the requirement process.
  • Organization: Organizational model and services delivered to stakeholders, the provision of resources and resource management in the delivery of these services, and the framework of process and tool governance.

 

Continue reading

Collecting Requirements Review Checklist

Project Managers need to ensure that the collect requirements phase has been completed satisfactorily. This checklist provides a reference for elements that need to be defined.

You can find the checklist here

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Checklist for Developing a Requirements Transformation Program

A Requirements Transformation Program

A program to improve the organization’s capability to develop and manage requirements in support of application development and other business initiatives.

A program to move an organization up a maturity ladder of requirements capabilities in the following areas:

  • Process
  •  Practices and Techniques
  • Technology
  • Organization
  • Deliverables / Results
  • Staff Competency

Building the Business Case

Generic statements concerning the value of good requirements will not be sufficient to support spending time, budget, and resources on a program to transform requirements in your organization. Whenever resources such as money or effort are consumed, a clear explanation of rationale is needed in business terms indicating quantifiable benefits.

It is always necessary to clearly explain the timeline and return on investment (ROI) that requirements improvement provides. Ongoing executive support is crucial for the success of a requirements transformation program.

  1. Use the Maturity Model as a framework for improvement
  2. Be forward looking, not backward looking
  3. Positive in reasoning, not negative
  4. Simple arguments get funded while complexity just confuses
  5. Be sensible about what can realistically be accomplished
  6. Spend your time asking good questions
  7. Get the hard facts: Include industry studies such as the CHAOS and BA Benchmark Reports
  8. Talk implication, not problem or need

Baseline Your Level of Requirements Management Maturity

  • To understand the relative strengths and weaknesses of the organization across multiple capability areas
  • To set a quantifiable baseline measurement to measure subsequent improvement against
  • To serve as a reference for directing requirements improvement on a targeted basis to best suit your organization

Creating a Requirements Practice Improvement Plan

  • To serve as a communication vehicle to the change process
  • To provide a common understanding to the organization of the tasks and target objectives of the change process
  • To serve as a reference for tracking progress against objectives

Click here to get the checklist

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Specifying Report Requirements

Good reports deliver business value. They give decision makers the information they need to take fast, effective action and save time, effort and money. 


There are three attributes to defining effective reports: Action, Stakeholder, Information:

Action:  A decision or task used to manage or operate the business. A Stakeholder takes Action using Information. Actions are measurable, no matter what they are called (“objectives”, “goals”, etc.). “Be informed” is not measurable. “Describe [situation] to executives” and “Satisfy regulators” are.

Stakeholder:  Someone, often a manager, who will take Action based on Information. Reports are created because the Stakeholder needs to make a decision or understand a problem. If you could automate the action it’s usually part of a process, not a report.

Information:  Data, aggregated and presented in a way that answers a question. Describe only the necessary data and formulae, the way the data should be structured into groups or summaries, and the best way to deliver the data.

Continue reading

BI Requirements: Success Enablers

A BI Project can only be successful if it actually gets built and if the Clients utilize it. Data Warehouse best practices indicate that there are some enablers toward making a BI implementation successful


Have Strong Executive Management Support

With executive sponsorship and involvement all challenges can be overcome; without it the project may be doomed from the start.

Ensure there is a justifiable business value to a the data requirements

Simply put, include data in the data warehouse that can result in measurable dollar benefits to the business itself. Data with no or little anticipated benefit should not be included “just because we can”. A Business Intelligence system can be an incredibly powerful management tool, or it can be a complicated, confusing and cumbersome monster that doesn’t get used or becomes unreliable.

Have strong client buy-in / participation throughout the Project’s Life Cycle

When business users actually provide the business requirements for the BI system they develop a stronger sense of ownership. Having an understanding of the design and content results in a significant improvement in overall adoption and utilization rates of systems developed with direct user involvement.

Continue reading

SCRUM: Playing Planning Poker

In order for the Team to provide a Commitment they need some way of estimating the work effort of the Product Backlog Items. To help teams determine their commitment level Scrum employs a rather unique way of estimating through a technique known as ‘Planning Poker’. Basically it works like this:

1. Each Team member (except the Product Owner) is given a deck of Planning Poker cards (that carry a value of between 0 and 200).

2. The team reviews each product backlog item and decides which is the smallest / least complicated item and assigns it a value (e.g. 2-points). It really doesn’t matter what units you use (it could be popsicle sticks for all that matters) as the estimates are all relative to each other.

3. Then, starting from the top the Team selects the first item from the product backlog

Continue reading

Understanding Your Role in a Requirements Session

1. Requirements Team (Facilitator, BusinessAnalyst)
Enable the requirements discovery process by:

  • Asking relevant questions
  • Recording answers provided by SubjectMatter Experts
  • Keeping the process moving
  • Utilizing effective facilitation anddocumentation skills
  • Keeping the discussion focused onobjectives and scope
  • Confirming understanding among/withparticipants
2. Business Leader / Project Sponsor
Provide the business vision by:
  • Explaining the problem/opportunity
  • Defining the vision
  • Defining the business objectives
  • Determining the measures of success
  • Defining high level process andrequirements

Key Questions for Breaking Through on a Difficult User Story

The Challenge

User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface.  Some should be broken up in to multiple stories.  You may not know how best to write a user story and communicate needs.  Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.

Break Through Thinking

Make this break through:  it’s not the designs you bring, or the solutions you suggest, that will clarify needs – it’s the questions you ask that determine how quickly a solution can be implemented.  Good questions showcase your understanding and build trust between you and the user.  Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:

 

Determining the success criteria

Here is a simple approach to clarifying user stories: attach your clarifications as acceptance criteria or test conditions.  The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.”  By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.

Continue reading