|Bob's Technique||Business Analysis Planning and Monitoring||Elicitation and Collaboration||Requirements Life Cycle Management||Strategy Analysis||Requirements Analysis and Design Definition||Solution Evaluation||Requirements per BABOK|
|Intended Use||x||X||x||x||x||Business Requirements|
|Assumptions, Capabilities, Limitations, and Risks & Impacts||x||X||x|
|Data Sources, Collection, and Conditioning||x||X|
(To-Be State: Abstract)
(To-Be State: Concrete)
(Functional and Non-Functional)
|Test Operation and Usability
All practice areas follow a similar problem-solving procedure — because it is essentially a specific form of the scientific method.
(That has proven to be pretty effective, right?)
Business Analysis is about identifying and addressing the customer's requirements.
The engagement is what we do to effect a change that serves customers.
The system is what we analyze and either build or change to serve customers.
The solution is the change we make to serve customers.
Link to detailed discussion.
|IIBA||PMI||Scrum Alliance, Scrum.org||ASQ and others||Other / Technical / Product|
|Business Analysis||CBAP, CCBA, ECBA||PMI-PBA|
|Project Management||PMP, PfMP, PgMP, PMI-RMP, PMI-SP|
|Agile and Scrum||IIBA-AAC, IIBA-CPOA||PMI-ACP, Disciplined Agile||CSM, CSPO, CSD, PSM, PSPO, PSD, plus many more|
|Process Improvement||Lean Six Sigma, Six Sigma Green Belt, Six Sigma Black Belt, Total Quality Management, Deming, others|
|Cyber Security||IIBA-CCA||tons of certs from different vendors|
|System Architecture||ITIL, TOGAF, BPMN, others appropriate to industry|
|Skill- or Product-based||tons of specific vendor certifications for languages and tools|
The practice areas are all specifically targeted problem-solving methodologies, so overlap is inevitable.
The relevant bodies of knowledge and training materials all mention the same concepts, artifacts, and activities, so we'll highlight the differences in emphasis.
For example, I reviewed about forty hours of material on Agile, Scrum, and Kanban last week, and they mentioned things like ROI, but it isn't a core part of the practice. In Project Management, they mention a lot of things I've discussed with you in the past, but more to say that they're things you need to do rather than how to do them.
|Area||Initiating||Planning||Executing||Monitoring and Controlling||Closing|
See differences from PMBOK 4.
Project Management concentrates on the engagement, but more technical knowledge is always better.
"Tell them what you're gonna say. Say it. Then them what you said." (see Dale Carnegie and Will Smith) -> "Plan the work. Do the work. Monitor and control the work. Close the work."
Project Management practices were initially driven by working in the style of Waterfall, but good managers have always incorporated feedback, correction, and adaptability.
The other practice areas tend not to talk about things like building teams, budgeting, and resource allocation, but you can bet somebody is thinking about and acting in those areas.
I think of Project Management (and Program, Product, and Portfolio management) as a wrapper around all the other practice areas.
Agile is a set of principles designed to address specific problems extant in the late-90s, but even its creators have moved beyond those concepts to something more general.
Agile and Scrum can best be thought of as ways to push decision-making and autonomy down to lower levels of organizations, to make them more adaptable and responsive by allowing them to apply their local knowledge most effectively.
This does not obviate the need for higher-level awareness and planning!
This discipline is trying to swallow the world, but how much of a standalone practice is it?
Many practices and techniques can be seen as general or for specific skill areas. Most of the material in the books shown isn't about Scrum and Agile, and is instead about specific software development practices.
Is Test-Driven Development (TDD) really part of Scrum (and the CSD), or is it part of general software development, that sometimes happens in Scrum? Or does it just support the cottage industry of workshops, certifications, and consultants?
Is horizontal vs. vertical slicing part of Scrum or general software design practice? Is the admonition to "always" avoid horizontal slicing a guideline or a hard-and-fast rule?
The vast majority of Scrum certifications are at the basic level, and that's probably as it should be. The majority of those are for ScrumMasters.
Unless an individual is supporting multiple teams, it is my opinion that a full-time ScrumMaster is a ridiculous waste of resources. This individual should be at least one other kind of subject matter expert.
While there's something to be learned from the practice of Agile and Scrum (and Kanban and SAFe and ...), if the whole certification track and industry disappeared tomorrow I wouldn't miss it. It doesn't teach much not available in the other practice areas — with the following exception:
It does get people thinking about talking to each other and iteratively reviewing their situations. If something has to continue, it should be as a single certification for all kinds of practitioners (with maybe another one for general software subjects).
Lean is about doing more with less (efficiency). Six Sigma is about reducing variation and hence errors and waste (quality). Lean is more of an art while Six Sigma embodies numerous specific analytic techniques.
Total Quality Management is driven by defining standards and finding ways to meet them.
W. Edwards Deming was a famous pioneer in statistical process control and overall quality. See his System of Profound Knowledge.
There are many different but related approaches to quality. The Toyota Production System is an overarching management approach with a strong emphasis on continuous improvement.
Process improvement is not only applied to existing systems. It should also be regarded as an integral part of the design process. For example, the design of the shuttle system at the DFW airport incorporated a full FMEA analysis.
The Lean Six Sigma Black Belt certification taught me the most and required by far the most effort and time.
Six Sigma materials often talks about "The Voice of the Customer" and "The Voice of the Process." The former is a strong overlap with Business Analysis, and of course all practices ultimately serve the customer, but the bulk of practices are technical.
The collection, conditioning, movement, transformation, integration, storage, documentation, analysis, safeguarding, display, communication, and management of data can be explored and pursued to as much depth as you'd like.
I've mentioned previously that data is both enumerative (qualitative nouns and verbs describing what's in a system and what it does gathered through discovery) and descriptive (quantitative adjectives and adverbs that characterize the elements of a system gathered through data collection).
Activities associated with data include artificial intelligence, machine learning, simulation, display and reporting, and historical recording.
Applications using data include optimization, design, trends analysis, risk reduction, economic analysis, and process control. (Think nuclear particle physics!)
Most of us frankly don't know much about cyber security, but we know...
We should know similar things about other practices we might encounter.
This is the specification of any system in any notation or language germane to and appropriate for its intended use.
Many different standards exist to define certain kinds of systems: TOGAF, BPMN, P&IDs, BIM, and more.
System specifications may have multiple facets or views (e.g., P&IDs vs. physical layout drawings for mechanical pulping systems, or P&IDs vs. isometric drawings for nuclear power plants).
Business Analysis: Discovery to learn what's in a process (possibly embedded within the design phase), Functional and Non-Functional Requirements.
Project Management: Work Breakdown Structure (WBS)
Agile and Scrum: Backlog development and grooming.
Process Improvement: Problem Identification, Fishbone Diagrams, Root Cause Analysis, FMEA
Data Analysis: All data items must be understood and classified. Discovery must take place first so you know what data to collect.
Cyber Security: All parts of the system and related processes must be identified, understood, and secured.
System Architecture: A system is built up from all the components needed to serve an intended purpose.
A lot of specific technical "how-to" information is buried in each practice area body of knowledge. It generally makes sense, but separating it out leaves the overall is-ness of each practice area.
Many practices appear in different bodies of knowledge.
While reading a book by visionary architect Paolo Soleri I realized that, no matter what you're trying to accomplish in life, you always end up trying to find the answers to the same questions. Examining the differences — and commonalities — between the different practice areas we've looked at, confirms this idea.
Business Analysis: How to analyze solve problems for (internal and external) customers, based on their requirements.
Project Management: How to arrange and manage the actual work, in whatever form it takes. It's a wrapper around the other practices.
Agile and Scrum: How to flatten teams and organizations to make them as autonomous, adaptable, and responsive as possible; how to push decision-making down to lower levels.
Process Improvement: How to make activities more consistent (and less error-prone) and use fewer resources.
Data Analysis: How to collect, condition, process, and analyze information in service of all other activities.
Cyber Security: How to ensure systems and organizations safeguard data and processes.
System Architecture: How to design and configure systems and use specific tools.
This presentation and other information can be found at my website: