BABOK Chapter Four: An Approach vs. A Step

While helping a certification study group run by my local IIBA chapter, we inevitably reached chapter four in the BABOK. Chapters three through eight describe the six main knowledge areas for business analysis. They are related to each other per a diagram in the version 3 BABOK (Figure 1.4.1), but that relationship isn’t linear or sequential.

When I discuss my framework for doing business analysis, I approach it from a more linear and sequential viewpoint, as shown here.

I’m always careful to say that my own framework is more a way of thinking about how to do things than a hard-and-fast prescription, as shown in the following figures.

Per the grid below, I observe that business analysis engagements can take many different forms, so the BABOK presents things in a diffuse way, more in terms of techniques and approaches than in terms of “do A, B, and C precisely in order.”

The left column shows the six major phases in my framework, along with the extra phases in a fully realized engagement. The top row shows the six knowledge areas in order as they are presented in the BABOK. I entered bold Xs in the grid where I thought there was an especially direct analog between how I think about things and how the BABOK presents them, and a muted smaller one where I thought there was a relationship but less direct. While I think of the BABOK’s approach and mine as being somewhat orthogonal, the BABOK describes approaches while I describe steps, you may note that the bold marks flow roughly from upper left to lower right, suggesting that both approaches tend to represent a flow through an engagement.

Addressing BABOK chapter four directly, as I represent below, I think it shows that Elicitation and Collaboration are performed in a cyclic manner, meaning the business analyst keeps engaging with the material with the customers and SMEs and stakeholders until everyone agrees on the results. This is why I illustrate my approach as a series of cyclic loops, where there is continuous iteration within each loop and also iteration forwards and backwards among the loops.

Let’s examine this diagram in detail. The darker blue items are the main activities in each chapter about the knowledge areas. Items 4.1, 4.2, and 4.3 involve preparing for elicitation, doing elicitation, and confirming the iteration, along with the lighter blue outputs that serve as the inputs for the next activity. I show them arranged in a circle, and have included a hatched arrow that isn’t described in the BABOK, to show that these activities proceed iteratively until full understanding or agreement is reached.

Item 4.4 involves communicating business analysis information. I always thought of this as sharing the outputs of the above cycle with the other stakeholders that weren’t involved in the given phase, but the BABOK show it as being a somewhat more independent activity.

Item 4.5 is about communicating with stakeholders, and that applies to almost everything that business analysts do. Looking at the representation of my six-cycle approach at the top of this post, it should be understood that the iterations in each cycle not only represent the work done by the BAs (and other practitioners), but also the communication and engagement with the stakeholders, and the internal communications and practices of the teams doing the work in each phase. The last clause may be understood more clearly if you think of a team from an external consultant or vendor providing goods and services to stakeholders in a customer organization. This naturally applies to all different kinds of practitioners working inside a single organization.

The form the iteration takes is different in each phase. In the intended use (problem definition), conceptual model, and requirements phases, the BAs are learning from the SMEs, and iterating until until they’ve demonstrated that they have developed a comprehensive and accurate conception of the current state and requirements for the future state. The flow is somewhat reversed in that the BAs are helping the designers, implementers, and testers deliver robust, working solutions that give the customers and stakeholders the solutions they need to do their work more efficiently and effectively.

Posted in Tools and methods | Tagged , , | Leave a comment

Roadmaps to Get Your Agile Transformation Out of the Ditch

My friend Mathew McConnell gave this excellent presentation for the Pittsburgh IIBA chapter this evening. The slides may be found here, and I encourage you to review the entire deck.

I’ve never spoken or written on this subject, but Matt covers it really well so I’m just going to review what he shared. I have been around this for years so I know he’s on target. One thing that makes this so clear for me is that I’ve been on program teams and product teams as well as on project teams (in almost every role), so I’ve had plenty of chances to see how products are managed, grow, and improve in response to customer needs and opportunities created by technological advancement.

Given the above, we might consider an ongoing effort where the backlog is always prioritized and always contains items that will be addressed in the near, medium, and long terms. Items are better defined that will be worked on soonest (or are being worked on right now!), and tend to be increasingly less well defined going farther ahead in time. Items are clarified and progressively elaborated as they move forward in the backlog and actually get worked on in turn.

There are many ways to communicate this information to different participants, but I tend to prefer just enumerating high level features in time-boxed buckets moving into the future. The priority of items will be determined by continuous review of the backlog by the product owner as he or she works with customers, internal teams, and other stakeholders. The information can come from any type of future work repository (e.g., Jira, MS Project, and so on). Here are some examples from Matt’s talk.

You can see that roadmaps can be conceptually organized by many different criteria. Many others are possible, especially if they are targeted to different audiences (e.g., developers, testers, managers, users, and so on).

Roadmaps apply in almost any management paradigm (Waterfall, Agile, hybrid, modification vs. from-scratch), but really shine over longer periods of time.

We learn from the study of economics that human wants are infinite and resources are inherently finite. Roadmaps are a good way to negotiate and communicate the choices you make.

Posted in Tools and methods | Tagged , , , , | Leave a comment

BA Webinar Series 11: Management Observations and Agile Deep Dive

Today I gave this webinar for the Tampa IIBA Lunch and Learn Series. The slides are here.

Posted in Tools and methods | Tagged , , , , , , , | Leave a comment

BA Webinar Series 09a: How to Unsnarl A Problem When You’re Dropped In the Middle of It

Today I gave this webinar for the Tampa IIBA Lunch and Learn Series. The slides are here.

Posted in Tools and methods | Tagged , , , , , | Leave a comment

BA Webinar Series 10: Business Analysis Overlaps with Other Practice Areas

Today I gave this webinar for the Tampa IIBA Lunch and Learn Series. The slides are here.

Posted in Tools and methods | Tagged , , , , , , , , , , , | Leave a comment

This Era’s “Great Project,” Revisited

The first post I wrote here, close to six years ago now, talked about a friend who bemoaned the fact that he wasn’t working on something singularly and identifiably great. My contention then was that, while the specific work wasn’t seen as great by the average person, it was indeed great because of its place in the larger sweep of history.

Yeah, yeah, I know this is bordering on sententious twaddle, but stay with me here. 😄

I took a lot of interesting notes while reviewing forty hours of material last week to renew my Scrum certifications, and I’ll write about and talk about those going forward, but today I wanted to highlight one particular idea. The specific thing that jumped out at me was the feeling that the conception, design, building, maintenance, and administration of ever larger, longer-to-build, longer-lasting, and more complex software systems is teaching humanity a lot about communication, organization, cooperation, adaptability, robustness, mutual respect and support, and belonging, and that’s an exciting thing to be a part of.

But then I thought, how much of this is really new? Large groups of people have always been organized to accomplish various ends, with examples being the pyramids and other great monuments and structures, military forces, government bureaucracies, and corporations. Indeed, the Tower of Babel story from the Christian Bible is all about the limits of how large a group can get before it becomes unmanageable. Certainly there have been large scale modern efforts like the space program and current infrastructure projects, and it’s clear that smart people have always been trying to organize them better.

I recently read an article, which I can no longer locate but will link here if I find it, that (I think) described how Michelangelo used a very flexible, adaptive process as he was guiding the construction of St. Peter’s Basilica. A number of architects had worked on the design over a long period of time (one of whom built wooden models for seven years before being replaced), but what made Michelangelo different was that he arranged the work in a way that allowed things to be tried by actually being built, but then quickly disassembled and changed, if necessary, after quickly seeking feedback from the extant Pope. This ensured that work was always directed toward the actual construction and not endless models and drawings that didn’t give true understanding of the reality. This example may not be about organizing large groups of people, but it is about finding efficient ways to seek and act on continuous feedback. As this was the last great project of Michelangelo’s career, he had doubtless learned an awful lot about what worked and didn’t work in the service of making his customer happy. His assistant was left to carry on after the his death, and continued to make changes in response to feedback, even as he worked mostly according to the master’s plans.

A large military force might be thought of as the most hierarchical thing you can think of, right? But there are hierarchies and there are hierarchies. General George S. Patton, in leading the Allied forces toward Berlin in the latter stages of World War II, said “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” I once suggested to my favorite platoon sergeant that the US military would be better than the Soviet military because our troops are trained to be more independent. He retorted, correctly, I think, that in a situation where people find themselves without their assigned commanders, “a leader will emerge,” and they’ll carry on with their full intelligence and capabilities. Bad things happen when control is held too tightly, as in the case where German commanders were afraid to act without direct permission from a sleeping and not-to-be-disturbed Hitler (at least as depicted in the movie The Longest Day) as the Allied forces landed at Normandy. The takeaway here is that organizations need to be flexible and adaptive enough to utilize the best ideas and energies of all participants. Those that do this better will tend to succeed; those that do this poorly will tend to fail.

Steve Jobs said similarly, applicable to a corporate setting, “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”

Here’s a description I wrote about a client’s existing process my company automated:

The company’s original process was fascinating. They had a formal system arranging documents in customized, 3–section folders representing each person in the company being considered for insurance coverage. All documents were punched with two holes near the top and were secured in the folders by built-in brass paper fasteners. The company then had a system for gathering the folders for all of a company’s employees and shuffling them around en masse so they could be processed by different groups of employees. The individual folders would be scored by the underwriters themselves, and would sometimes be routed to staff physicians or to personnel who would contact the employee’s doctors to ask questions about things in their medical records. (Since the personnel making these calls were not medically trained this sometimes annoyed the physicians they called.) The whole process was extremely clever and it was amazing what they had been able to accomplish with just folders, labels, and pushcarts. If you’ve read any of Jack L. Chalker’s Well of Souls series of science fiction novels you may remember that some of the regions on the planet where most of the action takes place were subject to various limits on the technology that was allowed to work. In particular he described a race of frog-like beings called the Makiem who lived in a low-tech region that only allowed muscle, wind, and water power. Nonetheless they had arranged a system of tubes and ramps that supported a semblance of advanced communication, distribution, and movement. It was not so long ago that all businesses and organizations had to operate using similar methods. The advent of computers has wrought a world of change.

Charles Darwin’s observations of natural phenomena led him to gel the impressions of his age into one of the most powerful insights in human history, that of self-organizing systems and emergent order. He didn’t necessarily put his findings into those words, but his many successors did, including the great economist Ludwig von Mises (though one of his students, Friedrich Hayek, is often given more credit for this line of thinking). These insights are being leveraged increasingly by managers, organizations, and agile practitioners to create working groups that are ever flatter, more autonomous, and self-organizing. It’s a big and often scary leap, but it’s an extension that goes beyond what has come before, and that’s the exciting part.

It seems that every generation has to learn from the wisdom of the past and adapt it for its own use. Technology may change, but the basic problems of life and human nature never do.

Posted in Management | Tagged , , , , | Leave a comment

Bringing Order to Collections and Systems

I’ve recently been putting together a bunch of related thoughts about how I do some parts of systems analysis and design. They involve bringing order to collections of items, data, actions, and ideas. I’ve written about one of the ideas explicitly before and touched on a couple of others. Here I wanted to go into detail.

Collections and Systems

So what are we trying to bring order to? Writing from the point of view of a business analyst or systems analyst it’s clear that this comes up in the course of our work. The collections of stuff we run into are part of the systems we are called upon to analyze, build, and improve.

The raw material of our analyses is gathered through various processes of discovery (identifying the nouns and verbs of what’s going on, see here, here, here, here, and here), and data collection (identifying the adjectives and adverbs that characterize what’s going on, see here, here, and here). As I’ve noted previously, discovery comes first so you know what data you need to collect.

The articles in the links describe many ways analysts learn about the items and processes under study, but I want to add a very important one: brainstorming. This is where people sit together and just vomit out every relevant thought they can about the subject under study. The interesting thing about this technique is that it usually, but not always, involves an associated step of grouping the ideas that seem somehow related.

Finding Commonalities

Here are just a few examples of how people find commonalities.

Frank Bunker and Lillian Moller Gilbreth, whom you may know from the book Cheaper By the Dozen, were pioneers of industrial management and time and motion studies. Through extensive observation they were able to identify a number of simple hand movements that manufacturing workers used in different combinations, and this insight was an important step in making processes more efficient, comfortable, and safe. These basic movements came to be called therbligs, based on a reversing the spelling of Frank’s last name.

When I did business process reengineering for FileNet implementations, part of the analysis I learned to do involved identifying similar operations that workers performed in different processes (I’ll call these departments) in the operation. The figure below shows an analysis of all operations identified in a particular department (each of which may have involved up to about fifty workers, as I recall), and the time per worker per day spent on each. The rows identify the unique operations performed by the workers in that department, so all rows have data associated with them. The columns characterized the general type of each operation. Since this list included all types of operations performed by workers in all departments of the overall process, not every column had entries for every department, but every column had entries in the grid for at least one department. It was the information in the columns that allowed us to determine which operations could be automated, and thus how much time and money could be saved. It also allowed us to quantify the new operations that had to be added to the reengineered process, the number of workers and computers required, and their ultimate cost.

I often say that a business or systems analyst is a kind of learning machine, since they have to learn the particulars of the specific things they are analyzing, but they also have to be communication and translation machines. That is, they have to be able to talk to a lot of different of people about a lot of different things, and somehow get them to understand each other. The more the analyst knows about everyone’s job and concerns, the better job the analyst can do.

He is a basic communication model I learned in a leadership school in the Army.

Potentially different techniques can be used to improve each step in the communication process, and this applies whether the communication is in person or electronic. One of the key things is verifying the integrity of each message, and retrying the message as needed until all parties agree that a shared understanding has been achieved. I describe this for electronic communication here (see references to retries), but for people trying to work together through a problem-solving engagement, I refer to the core iterative cycle in my analytic framework, as shown below.

This iterative process helps build understanding, trust, buy-in, and ideally enthusiasm from all participants, and is a form of finding common ground — or commonalities — between people.

Common themes are a hallmark of great literature. While Neal Stephenson’s Cryptonomicon may not be everyone’s idea of great literature, a lot of people think it’s pretty decent science fiction. The story draws parallels between cracking codes in wartime, industrial communications, and interpersonal relationships.

When I was about fourteen I tried to list all the different pieces of Lego I had collected. It wasn’t enough to just list them, though. My precocious, nerdy little self had to try to organize everything into some kind of a taxonomic hierarchy, and that’s where the project hit a snag. Which characteristics would be higher in the hierarchy? Color? Shape? Number and configuration of studs? Height? Something else? I remember that I chose some sort of precedence, but I’m pretty sure I was never really happy with it. Later on I learned about databases, programming, and the ability to sort, display, and analyze flexibly depending on the specific problems at hand. That made me feel a lot better about things.

I didn’t go back, enter all my Lego pieces into an Access database and run a bunch of different reports on them, but these experiences were formative and illuminating. For this conversation, it illustrates that there are many different kinds of commonalities to find. Which ones you find should emerge from the nature of each problem.

The foregoing is an example of there being several possible ways to classify items. By contrast, the Big Five personality traits were identified using only one type of classifying mechanism. As I understand it, they were derived by identifying every possible adjective people can use to describe aspects of a personality, and then a factor analysis was performed on each pair of words (I presume in every combination) to determine the degree to which they were related. When these were analyzed (I don’t profess to know how they did it), the adjectives seemed to fall into five distinct clusters. As someone who’s long been interested in Myers-Briggs personality typing (itself based on the work of Carl Jung), I’ve found this to be quite interesting.


As someone who has not only designed and built simulations, but also tools to build simulations, I have a keen appreciation for identifying opportunities to build the smallest number of unique components that can be customized to represent the widest range of entities or processes. I’ve discussed the basic components germane to the creation of discrete-event simulation models here. I documented the creation of my discrete-event simulation demo here, including 91 blog posts. I did something similar when I built a tool to document and calculate coefficients for fluid models.

Being able to identify, design, and implement reusable and reconfigurable components makes systems and architectures much more robust, understandable, documentable, testable, and so on. Said another way, it is a boon to improvement in terms of non-functional requirements.


Finding commonalities can help in the creation of modular designs, but it can bring order to situations in other ways. The best general word I can come up with to describe this process is rationalization. (In a good way, not as Jeff Goldblum’s character invokes the word in the movie The Big Chill.)

I analyzed the product line of controllers and software for HVAC systems to clearly identify what we had, which existing products should be maintained, which features could be added, and what made sense to develop as new products.

As part of this I identified most pieces of communication and functional capability in two dimensions (heirarchal layers on the vertical, protocol or function on the horzontal) on a Visio drawing, and then I created layers for each product the company made, where the relevant elements could be turned on and off as the analysis proceeded. That pointed to ways to make the existing product line more uniform and where it made sense to add new protocols and develop new products entirely. As I review this now, this could have been accomplished a bit more easily and compactly using a spreadsheet.

Sometimes rationalization just means figuring out ways for people to find things. I describe my proposals for monitoring an entire microservices stack across five levels here. This proposal grew out of the need to make the system understandable and manageable, because it was a total fire drill when anything went wrong, with people needing to scatter all over the place to figure out what was happening. This could have been avoided if the information and tools had been organized and placed in a known location where they could be readily accessed and controlled.

I linked to the discrete-event simulation tool I developed as a proof-of-concept (and proof-that-I-could-develop-in-JavaScript) demo above. Each component was different, but I wanted to ensure they implemented similar features in the same way. Here is one discussion that describes a sliver the process I went through (note that the images are scrollable).

Any form of automation can be thought of as a kind of rationalization, because it tends to make each repetition of an action more consistent and repeatable. If structured properly, this can also help reduce errors, build understanding, and improve situational awareness.

As you can see, rationalization can take many forms. It’s just a form of putting things in order — while simultaneously making them consistent — in a way that make sense for each situation.

Final Thoughts

My desire, when I get the chance to make it happen, is to have other people understand that these processes are similar to those of the iterative customer/team feedback cycle I mention above (and often), in that one is always aware of the full process going in and tries to make use of this knowledge throughout any work effort.

It can take the form of getting practitioners to use similar methods and best practices across different activities, can be supported via internal and external communities of practice, and be facilitated by information shared in meetings and through websites and shared communication portals like Confluence and Slack, among many others.

If you can think of any other examples of how you’ve done this, and what did or didn’t work for you, I’d love to hear about it.

Posted in Tools and methods | Tagged , , | Leave a comment

BA Webinar Series 09: How To Unsnarl A Problem When You’re Dropped In the Middle of It

I recently gave this webinar for the Philadelphia IIBA monthly meeting. The slides are here.

Posted in Tools and methods | Tagged , , , , , | Leave a comment

Post University CIS Advisory Board Meeting 2021

Yesterday I participated in yet another of Post University’s Advisory Board meetings for its CIS department (see descriptions of previous years here). The participants included individuals with widely varying experience and perspectives, and it’s always interesting to hear what they have to say. What follows are my own suggestions, based on topics from the agenda, other advisors, and my own observations.

General Topics, Business Analysis, and Soft Skills

I noted that their department is targeted to CIS (computer information systems) and not pure computer science. That means that the context is more about working in different capacities within an organization than going down the rabbit hole of maximum performance and finding the next incremental advance in algorithms and data structures. That suggests that students might benefit from being exposed to a wide variety of concepts during their educations, including core:

  • Algorithms and Data Structures: You gotta start with the basics. This means you typically start with a single language, but it’s a good idea to be exposed to more than one language and some discussions of the applications of and differences between each. When I went to college, must of us started with Pascal, but being exposed to C and assembly language was helpful in beginning to explore the wider world of computing. Since then I’ve worked with or studied close to twenty more, and there are reasons why they all exist. A few of them are and can be expected to remain in widespread use (JavaScript, Node, Java, Python, GO, R, Swift, PHP, C/C++, and C#), some will continue to fade but never completely (FORTRAN, BASIC, Ruby, COBOL), and others may break through or remain in niche uses (Rust, Dart, Opa, Scala, Erlang, Ceylon, Golang, and Hack).
  • Architectural Arrangements: Solutions are built in many contexts, including web-based, microservices, client-server, peer-to-peer, desktop and other standalone, mobile devices, embedded, and IOT. Some will clearly be more germane to CIS graduates expecting to support organizations, but it’s good to be aware of everything that’s out there.
  • Collaboration Tools: Industry tools like SharePoint, Jira, Confluence, Rally, Slack, BaseCamp, Discord, Zoom, Github, email, MS Teams, Azure Devops, and more. Nobody does anything alone any more, especially of any scope, scale, or complexity.
  • Desktop Apps: MS Office apps like Word, Excel, and PowerPoint — or their “free” equivalents from Google, Apple, and others; diagramming tools like Visio, data presentation tools like Tableau and PowerBI, various utilities, and so on.
  • Operating Systems: Unix and Linux (everything from Red Hat to Raspbian for the Raspberry Pi), Windows, Apple desktop, iOS, Android, and others.
  • Management Paradigms: Waterfall, Agile, Scrum, Kanban, SAFe, local vs. remote including offshoring, and work at client sites and consulting.
  • Other: ERP suites, automation and configuration tools (e.g., Jenkins), low-code and BPR platforms (e.g., FileNet, Appian)

Per a discussion of soft skills, I brought up the work I’ve done for my presentations on business analysis, where I often discuss the need for feedback, being thorough, communication models, and generally getting people with different skills and needs to talk to each other. Business analysis is really about the larger context of solving problems as a group, from the point of view of practitioners who can be involved in every phase of any kind of effort. The BABoK (Business Analysis Body of Knowledge), published by the IIBA (International Institute of Business Analysis), describes a wide range of tools, techniques, and general approaches to helping people work together. The sections run as follows:

  • Chapter 1: Introduction (structure of the BABOK)

  • Chapter 2: Key Concepts (basic context of business analysis)

  • Chapters 3-8: Knowledge Areas (the basic flow of what gets done)

  • Chapter 9: Underlying Competencies (Analysis, Behavior, Domain Knowledge, Communication, Interaction, Tools/Tech)

  • Chapter 10: Techniques (50)

  • Chapter 11: Perspectives (Agile, BI, IT, Business Architecture, Process Management)

  • Appendices

…with chapters three to eight generally providing guidelines to work through any kind or project, program, or engagement in a logical order.

I’ve distilled this material down into a more streamlined framework I’ve developed after having worked in many different industries, on efforts of widely varying scope and scale and team sizes, with many different architectural considerations, for many types of target applications, in many kinds of environments all over the world, often while creating, deploying, and using computer simulations. I put this together as a way to give business analysts and project managers a feel for how problems could be effectively addressed and worked through, usually in a team setting where not everyone knows what everyone else is doing. I feel this helps everyone communicate better, be more organized, and produce better work with less wasted effort. The framework is flexible enough to be applied to a variety of working situations.

Thinking back to my own college education, and the things I came to know throughout my career, especially early on, this is material that would have made my life a lot easier, and would have made me a better employee and teammate, if I’d been exposed to it as part of my curriculum. This is despite the overall high quality of the instruction I received. In short, this is very close to what I wish I could learn first if I had it to do over again.

One additional benefit of my efforts is that I’ve come to a much better understanding of the strengths and weaknesses of the processes used by the many organizations I’ve worked for. All had strengths and all had weaknesses, and that raw material gives me a lot of direct experience to work with. (I’ve been meaning to write a separate blog post about this; I need to make it happen.)

As much as I like certifications (which I discuss below), there’s a time to know enough is enough. I often point out that the Wikipedia article for every management or industry-certified approach includes a section for criticisms. They range from the body of knowledge being too diffuse to be useful (e.g., ITIL never gives you specific recommended procedures that lead to specific results), that certs don’t guarantee their holders know anything useful (any Scrum cert), or that they create expensive and wasteful cottage industries of consultants and educators (all management certs). To avoid this, while trying to concretize the material in the BABoK, I present the core engagement steps as a series of iterative loops that involve lots of communication, feedback, and correction. Additionally, the framework builds in the flexibility to iterate between phases to modify and add or delete items in previous or later phases. Like I said above, it’s all about getting people to talk to each other.

I’m especially fond of a talk given by one of the people who helped create the Agile Manifesto. He cheekily suggests that Agile Is Dead, and that what we really need to do is talk to each other, make sure understand each other, make sure we agree we’re doing the right things, and make corrections after so talking. His presentation is on Youtube here, and cannot be recommended highly enough.

Being supportive, engaging, understanding, respectful, and kind — while not wasting people’s time and money — is the best soft skill you can have.

I describe my basic framework here.

I expand on the material in a series of webinars here. The slides for a ninth presentation are here.

The slides for all of my presentations are most easily accessed in the Presentations article here.

AI, Machine Learning, and Data

As an erstwhile mechanical engineer I was never going to be a great computer scientist, even if I probably took as many or more computing courses as any engineer who didn’t get at least a formal minor in the subject. When I took the second level CS course (15-211) in 1983, they covered tree structures, dynamic allocation, and predicate calculus, which was a way of evaluating the truth or falsity of statements written in formal logic. They also talked about how computers could (in theory) understand and describe the world in terms of objects and movements and qualities that could be sensed. I also worked on a year-long senior project and independent study course to create an interactive system to teach engineering students how to solve certain classes of engineering problems. It had a (very rudimentary) natural language interface and maintained situational awareness of where the student was in the process and what ideally needed to be done next. This experience led to a lifelong sensitivity to developments in the (so-called) artificial intelligence field. It similarly contributed to a lifelong interest in education, and its automation and improvement.

One of the main things I’ve learned from watching developments in AI and associated understandings of the brain, nervous system, and sensory systems, is that the more we learn, the more we learn how much there is to learn. The big breakthrough is always thirty years in the future. It was true in 1983, it’s true now in 2021, and I suspect it’ll still be true in 2059.

That said, we do continue to learn and a lot of interesting and useful work is getting done. The question is how much of it to cover in an undergraduate CIS program. I think that students should definitely be given some awareness of the field, and even some exposure to the basics. One of the advisors noted that to researchers in AI can make quite a lot of money right out of school, but that’s for pure computer scientists at top schools (and I know I’m not one of those). Like everything, there are ranges of activities in AI, and some will inevitably be more accessible than others. Data Science and Machine Learning are definitely on the more accessible end of things. For example, a Udemy course on the R programming language covers the following algorithms in order of increasing complexity: Linear Regression, Logistic Regression, K Nearest Neighbors, Decision Trees and Random Forests, Support Vector Machines, K-means Clustering, Natural Language Processing, and Neural Nets. The course doesn’t take the time to go into the algorithms in much detail, and Linear Regression can hardly be considered any kind of AI, but is does show students how to use them. I’m certain that Post University can cover that material and cover it better and more deeply.

I also know that the CIS department includes courses in data structures and databases, so students are already touching on the handling of data, and possibly in large quantities. I think it would be beneficial to include some kind of survey of the contexts in which data are used. I do this in webinar eight of my BA series, which discusses how data may be handled through the course of an engagement, but there are many other contexts including policies (PII, HIPAA), workflow (data pipelines and workflows), display and dashboards (again, Tableau and PowerBI just to start), controversies with Big Tech, collection and conditioning, and automated assistants (Siri, Cortana), among others.

Professional Certifications and Student Portfolios

College diplomas have generally been seen as proof that students can show up regularly, can accomplish certain goals, can reasonably follow directions and cooperate with others, and have a certain amount of intelligence. Grades can communicate another level of information to potential employers, as can impressions made in interviews. But it can be even better to have more visible and specific proof that students have mastered skills and completed projects.

One way is to create and maintain some sort of online presence. This can take many forms, but two main ones are Github repositories, which is most useful for developers, and portfolios, which generally take the form of personal websites. If someone is really clever they can deploy their personal website directly from Github, which would be the best of both worlds. Most of the work on a portfolio site should be original (which could definitely include student projects) or at least non-proprietary. And even then, a portfolio can include quite detailed descriptions of work done for employers. (I do this quite often here on my own site.)

Public websites like LinkedIn and possibly Instagram can host a certain amount of material as well.

Another proof of competency is to earn professionally recognized industry certifications, of which there are many kinds. Certifications may be issued by companies like Microsoft, Google, and Amazon, by industry organizations like IEEE, IIBA, and PMI, or by independent educational companies like Udemy, W3schools, and Codecademy. They may be related to general skills like networking, project management, security, or process improvement, or specific products or technologies like Oracle, AWS, or CISSP.

Like anything, certifications come in ranges of expense, difficulty, time to complete, and general heft. Some have formal work experience requirements. The mid- and top-level IIBA certifications, for example, require applicants to document 3,750 and 7,500 applicable work hours, respectively. Some certifications require that applicants have completed some number of hours from an approved industry education provider or as part of an approved independent study group. In other cases it’s possible to simply read a reference book and pass the exam, though having an awful lot of related experience greatly improves the chances for success. Some certifications will probably be too expensive and take too long to even consider.

The department heads will have to give serious thought to what kinds of certification might best serve new graduates.

Here are a few approaches Post might consider, though I’m sure the department can dream up some other clever approaches.

  • Structure one or more formal courses that lead directly to industry certification. This would include educational hours, practicum, test prep, and collaborative study. The university would have to work out what surcharges, if any, would be needed to cover the cost of exams and materials from third party certifying organizations.
  • Become a certified educational, and perhaps testing provider for some industry organization(s), or become a recognized chapter.
  • Establish and nurture independent communities of practice aimed at earning specific certifications.
  • Give formal school credits for certifications students earn on their own (or in communities of practice described above).
  • Work out student discounts for certifications with certifying bodies.


Thank you as always for allowing me to participate.

Posted in Software | Tagged , , , , , , | Leave a comment

BA Webinar Series 08: Data: How To Get It and How To Use It

Today I gave this webinar for the Tampa IIBA Lunch and Learn Series. The slides are here.

Posted in Tools and methods | Tagged , , , , , , | Leave a comment