Chuck’s Snippets 11.0; page 1 of 10
National Flagship Project World & World Congress for Business Analysts, Orlando, FL
November 18 – 21, 2008
Friends and Colleagues,
Welcome to “Chuck’s Snippets 11.0!”
I would like to share the different learning approach I took during this conference. There is a great deal of focus and study on an identified gap in the PMBOK® (in theory and in practical application) around precursors to project authorization; current state business process definition, future state definition and the resulting gap analysis. Of course, the gap analysis is the foundation for defining requirements and becomes the scope of work projects are expected to deliver. Discussions with our project management practitioner peers frequently funnel to issues and challenges around requirements; including requirements definition, requirements management, user contribution, etc… This unfortunate reality is validated over and over through both primary research I have conducted with practitioners and secondary research published in our professional publications. To learn more about how the business analysis community is addressing this opportunity, I primarily attended workshops in the “Evolving Role of Business Analysis” track. Deviations included the combined keynote speakers and the first day of the PMO Forum that I opened with a discussion on “The First 365 Days of the Churchill Downs Incorporated PMO.” The content below captures the highlights from the workshops I attended.
The mantra for this conference was “Real People Sharing Real Results: Strong Leadership Calls for a Balance of Agility and Process.”
If you are interested in discussing any of the specific topics and/or speakers in more detail, please feel free to contact me.
Previous “Chuck’s Snippets:”
Version 1.0: Nov 2006 – National PW & WCBA, Orlando, FL
Version 2.0: Jun 2007 – Regional PW & WCBA, Boston, MA
Version 3.0: Nov 2007 – Northeast Florida PMI Regional Seminar, Jacksonville, FL
Version 4.0: Nov 2007 – National PW & WCBA, Anaheim, CA
Version 5.0: Apr 2008 – Nashville PMI 2008 Spring Symposium, Nashville, TN
Version 6.0: Apr 2008 – SW Ohio PMI Mega Event, Cincinnati, OH
Version 7.0: Jun 2008 – Regional PW & WCBA, La Jolla, CA
Version 8.0: Sep 2008 – TampaBay PMI Symposium, Tampa Bay, FL
Version 9.0: Oct 2008 – PMI Global Congress, Denver, CO
Version 10.0: Oct 2008 – Center for Quality Management Conference, Erlanger, KY
My standard disclaimer: While I believe all of the content of the attached summary is extremely valuable, I do not fully accept each premise or believe that all of the concepts would fully apply in every organizational environment. However, these basic principles of effective management, leadership, and project management are definitely worthwhile contributions to our professional development.
Remember…if you do not want me to send you these summaries, slap me down electronically, and I’ll remove you from the distribution list.
Speaker: Pat Williams, Author & Senior Vice President of the NBA’s Orlando Magic
Topic: The Magic of Teamwork
- The 8 qualities (or ingredients) of a high-performing team
- One: Great teams have outstanding talent
- It is amazing how many corporations do not fully understand the necessity for strong individuals to make a strong team. One of the barriers is that strong people can be intimidating. Like everyone else, they have issues, personality defects, etc… The fact that they’re “strong” individuals often highlights the imperfections that would be hidden, or less noticeable, in less “visible” contributors.
- It is easy to allow the below average, or less than talented, to stay on the team. The reality is that this limits a team’s potential for growth. There is undeniable evidence that leveraging strength is a dominate approach over building on weaknesses. Why do we continually allow people without the necessary skills to stay on our team? Something to thing about…
- When you locate a talented resource, here are questions you might consider before assuming they’re a good addition to your team.
- Will the resource allow coaching and teaching? Do they realize there’s an opportunity to improve? Self confidence is great, there’s such a thing as being over-confident in one’s ability.
- Does the talent understand and accept their role? Not everyone is the team lead. Not everyone is the highest paid contributor. Not everyone has the most respected title. In short, can they accept the role description provided and contribute to the team in that capacity?
- Is the talent willing to be a teammate? Is their goal to be the best contributor, the most recognized, etc…or to be the best teammate that anyone could have?
- Two: Great teams have outstanding leadership
- There has never been a team, and outstanding team, in any field, sport, company, or war that did not have outstanding leadership with the following characteristics:
- Vision: A focus on change and the future state.
- The ability to communicate their vision: If you cannot share your vision, you cannot lead a team towards realization of the future state.
- People skills: The best leaders have a “heart” for people. They are interested in their team, love their team, and empathize with their team.
- Character: Do your team members, peers, and leadership see the leader as someone that is honest and as someone that has integrity? Do they regularly meet commitments? Do they only promise what they can deliver?
- Competence: Leaders are good at what they do. There’s an ongoing debate if leaders are born or made. Pat contends that leadership can be developed and that not all leaders are born. This is evidenced by the plethora of leadership books, seminars and workshops that we invest in on a regular basis. The goals of these resources are to “develop” the ability to lead.
- Leaders are problem solvers. They understand the concepts of critical thinking and apply a structured approach to decision making.
- Leaders are teachers. Learn how to share your knowledge. Teachers are learners, which implies that leaders must be learners too. Pat challenged us to read a book every week (or month). He used the following logic (seeded in reality)… After you read five books on a topic, you are considered a subject matter expert. If you read one book per week, you are a subject matter expert on at least 10 additional topics per year. If you read regularly and develop that habit, you will be a subject matter expert on over 50 topics in five years. Eventually, you’ll be the SME sought after because of your breadth and depth of knowledge on multiple topics.
- Boldness: Leaders have to make decisions and execute. Leaders are not afraid to make decisions and/or mistakes.
- Serving heart: The best leaders understand they are not in a leadership position to dominate. They are there to serve their team.
- Three: Great teams are committed
- To each other
- To excellence
- To competition: Welcome competition. It makes you better and forces you to realize potential that may never have been released.
- To win: Literally. We are measured by our wins and losses…so what are you doing to help your team win?
- Four: Great teams are passionate about what they’re doing
- If you’re not happy, why do you continue to do what you’re doing? If you’re not happy, what are you doing to change your situation?
- You have to love what you do to realize your full potential. It is not illegal, immoral, or even “out of line” to have fun at your job and in your team. Can you image the potential energy if everyone on your team was having fun?!
- Five: Great T-E-A-M-S are always aware of the “team” environment
- Together, Everyone, Achieves, More, Successfully
- Six: Great teams empower each other
- You can tell that teams are performing as a unit when they are building up each other from within the team, enjoy each other’s successes, and encourage each other.
- Seven: Great team members respect each other
- The best performing teams have members that trust each other. The biggest challenge here is that a single member that is not trusted can bring down an entire team. Leaders…are your team members trustworthy? If not, why are they still on your team?
- Eight: Great team members exhibit the character expected of leaders.
- They tell the truth – You never have to question their word.
- They exhibit integrity – Their walk matches their talk (at work and at home).
- They accept responsibility – They are self-accountable for their actions and decisions.
- They’re willing to work hard – There’s no such thing as a free lunch. No one wants to carry the load for a team member for extended periods. If they’re not contributing, they’re off the team.
- They exhibit perseverance – Not every task, project, deliverable, etc…is easy. Things might be hard, but that’s why there’s a team.
- They have courage – The desire and ability to take a stand and do the right thing, even when it is not popular.
Speaker: Sunil Chandra, Director of Human Resource Technology & Operations, Google
Topic: Accelerating Fast; Technology & Operations
- Leaders and employers have to be able to evaluate the factors and changing influences on employee expectations. For example, today’s generation expects the same level of technology at work that they can get at home. Consider this…this is the first time in history that employees have access to better, faster and easier to use technology at home than they do at work. Guess what…so do your customers!
- The compression of time will only accelerate. You have to be able to change quickly. Evaluating the factors that influence employee and customer perceptions will become increasingly important. Share information…they’ll get it anyway. Share information quickly to control and influence perceptions.
- You cannot control information sources (especially external); however, you can influence those information sources. Be quick to communicate.
- Employers…use retail technology. Your employees understand it. For example, encourage instant messaging as a form of communication. The newer generations have less tolerance for asynchronous communication. Consider this…how often do you send an email and sit at your computer waiting for a response? Email is not synchronous. Using technology in a synchronous fashion can help you close a transaction or make a decision in a single meeting, session, etc…
Speaker: David Bieg, Executive Vice President, DevelopMentor & Chief Operating Officer for the International Institute of Business Analysis (IIBA)
Topic: Enterprise Analysis: Building a Business Case that is Aligned with the Strategies of Your Business
- Chuck’s Comments: An unfortunate reality is that even with increasing project management maturity, organizations tend to focus much more on tactical project management than strategic project management, which leads to competing priorities, poor coordination, and a tendency to ‘over’ promise and ‘under’ deliver. In my humble opinion, the project management profession has, to some degree, neglected the link between effective management of projects and effective strategy execution. The BABOK (Business Analysis Body of Knowledge) is a step towards filling that gap. David’s topic focused on enterprise-level business analysis that leads to project approval.
- Enterprise analysis (EA) is the collection of pre-project activities necessary for capturing the future view of the business.
- Key EA responsibilities:
- Document the business architecture
- Roles and responsibilities: Who is responsible for doing what?
- Processes: How is the work completed?
- Deliverables: What is the tangible output of the business processes?
- Training: Documenting how people learn to perform their work processes
- Business “visioning”
- Outline new project scope, business objectives, and assumptions
- Define the current state, future state, the “opportunity/benefit” expected and the associated metrics
- Identify stakeholders (up-stream and down-stream impacts)
- Feasibility analysis: This is the sum of the pre-project authorization activities that provide the decision making support information necessary to authorize a project. This includes:
- Documenting the “idea”
- Developing the business case
- Assessing risks to the business (impacted areas and/or processes)
- Supporting the request evaluation to facilitate a go-no/go decision
- Provide decision support information to facilitate project prioritization
- Salient point: Investment decisions are only as good as the process for building a business case.
Speaker: Kathleen Barrett, President for the International Institute of Business Analysis (IIBA)
Topic: A Primer to the Business Analysis Body of Knowledge (BABOK)
- IIBA background:
- Founded in October 2003
- Incorporated federally as a non-profit association in April 2006
- Similar to the PMI and the PMBOK, the IIBA has authored the BABOK (Business Analysis Body of Knowledge) reflecting generally accepted practices in the Business Analysis community.
- Mission: Develop and maintain standards for the practice of business analysis and for the certification of its practitioners.
- Some interesting statistics on the IIBA (as of October 2008)
- Members: 7437
- Chapters: 70
- CBAPs (Certified Business Analysis Professional): 458
- Chuck’s comment: While the numbers represented above are orders of magnitude lower that the PMI’s, I have found that the IIBA has identified, and is addressing, a quantifiable business need. The IIBA is also seeking ISO (International Standards Organization) 17204 approval for their certification. ISO 17204 is an international standard which sets criteria for an organization’s certification program for individuals. How cool is that?
- Business analysis is about understanding:
- How an organization works
- Why the organization exists
- What are the organization’s goals and objectives
- How does an organization accomplish those goals and objectives
- How does an organization need to change to better accomplish those objectives and/or overcome challenges
- Chuck’s comment: How can we know if a requested project supports the business model if there’s not a fully documented business model? Understanding the business model and how a project supports the organization’s ability to meet business objectives is the beginning of the traceability between a proposed solution and business goals. Reality check: Project management is in the middle of these two.
- Definition of a Business Analyst (BA): Works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies, and information systems.
- BA skills:
- Analyze & solve problems
- Understand the business
- Communicate effectively
- Manage client relationships
- Facilitate discussions
- Negotiate & build consensus
- Model data & processes
- Plan & manage activities
- Facilitate & develop business strategy
- Understand & manage organizational change
- Chuck’s comment: While a project manager owns “project scope,” there’s much more to realizing the full benefit of a project than delivering the product or service. The BABOK incorporates front-end activities (such as describing and defining the proposed solution) and post-delivery activities (such as solution implementation and operations) into the BA’s set of responsibilities. The question that begs to be asked is, “Is there an overlap of responsibilities between the PM and the BA?” The answer is yes! However, I am confident that the two professions can coexist. The BA skill set is not exactly the same as the PM skill set. Both skill sets, and both BOKs, are necessary for maximum benefit. I believe there may be small turf wars here and there, but do we not preach that healthy conflict is good and can lead to better solutions? Hmmm…
- A BA is responsible for the set of tasks, knowledge and techniques required to identify business needs and determine solutions to business problems.
- BAs should understand the end-to-end business processes to allow them to uncover opportunities (potential projects) for improvement to help maximize profit and/or efficiency.
- The BA also deals with the age-old issue of requirements prioritization. Their BOK specifically addresses how to coordinate and prioritize requirements to avoid the tendency to desire “perfection,” while leading the stakeholders to define the “need” to get the desired business results.
- The BABOK knowledge areas are:
- Business analysis planning and monitoring
- This knowledge area (KA) focuses on planning for the BA processes and activities.
- This KA answers the question, “What does the BA need to do?” In short, how the BA tasks will be performed, the deliverables, how changes will be controlled, etc…
- Enterprise analysis
- This KA focuses on understanding the business architecture, business processes, business goals, strategic planning, and business case development.
- This KA answers the question, “Why are we doing this?”
- Chuck’s comment: These are the very areas that many project managers claim they would like the “business partner” to support or understand more fully before requesting a project.
- This KA focuses on gathering requirements from various stakeholder groups and the various techniques used to capture requirements.
- This KA answers the question, “What do the Stakeholders need?”
- Chuck’s comment: This KA specifically addresses the primary causes of project failure…specifically, defining requirements (which becomes the scope of work projects are expected to deliver) and the issues and challenges around requirements…definition, management, user contribution, etc…
- Requirements analysis
- This KA focuses on transforming the business need into clearly described capabilities, identifies gaps in requirements, defines the “solution” capabilities and can serve as the foundation for selecting among solution alternatives.
- This KA answers the question, “What must the solution do?”
- Chuck’s comments: I’ve included this in previous Snippets… If your business partners do not have time to define requirements and still think the request is critical to the business, find out what they’re doing at that moment to meet the business need. Explain that if they do not have time to define the requirements for the desired solution, then they can “keep doing that.” This approach is not a silver bullet, but it can get attention.
- Solutions assessment & validation
- This KA focuses on ensuring the best approach is chosen, that the solution will meet stakeholder expectations, that the solution is feasible, and guides solution “verification.” This process is designed to be iterative; from paper-based solution assessment and validation to testing processes.
- This KA answers the question, “Does the solution do what it is suppose to do?”
- Chuck’s comment: This is very similar to the concept of Scope Verification. This KA includes verification that the solution is acceptable prior to implementation. As many of you have heard from me before, I am an advocate of “in-process” Scope Verification that iteratively validates scope at specific, or defined, milestones. In my personal experience, this is a frequently overlooked Scope Management process. Shame on us PMs…remember PMBOK process 5.4?
- Requirements management and communications
- This KA focuses on presenting and communicating documented requirements to all stakeholders, including project team members, to bring the group to consensus on project scope. Requirements management, analogous to scope management for PMs, is also included in this KA.
- This KA answers the question, “Does everyone understand and agree?”
- Chuck’s comment: Similar to Scope Management and “in-process” Scope Verification, requirements management and communication involves ensuring expectations are proactively managed. While Scope Verification focuses on “completed deliverables,” this KA includes the ongoing, dynamic management of requirements.
- Requirements categories
- Business requirements
- High level statements of the goals, objectives or needs of the organization (enterprise).
- Chuck’s comment: These are directly related to the “Business objectives” that are included in a standard project charter.
- Stakeholder requirements
- Documents the specific needs of particular stakeholders.
- Chuck’s comment: In project management, we generally refer to these as user requirements. While these may be considered business requirements, documenting stakeholder requirements as a requirements “category” can help with managing stakeholder expectations.
- Solution requirements (often called “technical requirements”)
- Functional requirements – The capabilities the system will be able to perform, or a specific system action or responsibility.
- Quality of service requirements – Environmental conditions under which the solution must remain effective or qualities that the system must have.
- Chuck’s comment: These are similar to what I have always called Service Level Agreements (SLAs).
- Assumptions and constraints – Are aspects of the problem that are not functional requirements of a solution, but will limit or impact the design of the solution.
- Implementation requirements – Are capabilities that the solution must have in order to facilitate transition from the current state to the desired/future state. These are usually temporary requirements. For example, data migration from one platform to another may be an implementation requirement.
Un-attributable, but salient, comments captured: These are notes that I took during different discussions and simply cannot link them back to a specific author.