What To Be Aware Of Going Into A Project

Short answer: everything!

Long answer: let’s actually talk about it.

The more you understand about the things you might encounter when you try to solve a problem, the more likely you will be to make use of the right people’s skills, be aware of things to look for during discovery and data collection, specify requirements for, include in the design, implement completely and efficiently, and test thoroughly and appropriately.

How to Prepare to be Aware of These Items

There are multiple ways to develop awareness going into a project.

• Personnel: “Our most valuable asset is our people!” announce motivational signs in organizational facilities so often it’s a cliché. Things become clichés, of course, because they arise from a large element of truth. The knowledge gained in the following items is still embodied in individual humans, and even if AI proves capable to performing some of this analysis (about which I remain skeptical even now, having followed developments in the field for forty years), it would still have been seeded by the knowledge and experience of people. Moreover, any results generated by AI would have to be verified and validated by people.
• Training: This involves arming people with knowledge they will need ahead of an engagement. The most striking example of this I experienced was taking a one-week operator training course at a nuclear power plant prior to starting a project to build a site-specific training simulator for it, but this training can take many forms and concern any of the factors discussed in the remainder of this article.
• Organizational Knowledge and Lessons Learned: Whatever knowledge is not embodied in people will (or should) be embodied in organizations’ historical documentation, policies and procedures, and existing codes and plant. These materials will need to be reviewed and possibly reverse engineered, but the knowledge is there and can be crucial.
• Research: Anything that isn’t already known can be learned, and from any appropriate source. I differentiate research from training by observing that training involves knowledge given while research involves independently seeking it.

Solution Components

Different aspects of solutions must be considered. There is a tendency to think about IT processes and solutions by default, but that should be resisted. Solutions, and process solutions in particular, can involve a wide variety of physical, logical, informational, and calculation-al facets whether they are primarily physical (e.g., security inspections and border crossings and airports, manufacturing lines, business processes that involve paper documents, and retail establishments), primarily informational (e.g., news and media websites, video games, design and analytical simulations, and online discussion forums), or a mixture of the two (consider that Amazon.com, Starbucks, and border crossings combine many physical and IT elements).

• Process Components — Abstract: Some solutions involve performing analyses that lead to specific items rather than processes, and those analyses are necessarily different. For engagements that analyze and then create or modify existing processes, analysts should be aware of entities, entries, exits, process stations, queues, paths, bags (or pools), resources, states, and so on, as described here. All processes are made up of the same basic set of abstract, logical components, no matter what they do and what elements they include.
• Physical Equipment — Non-Computing: This includes the physical process items like machines and storage components (like queues, tanks, hoppers, parking lots, and yards), the buildings in which they are housed, and the pathways between and through them. A Starbucks will involve a physical space of some kind, counters, furniture, restrooms, cold and room-temperature storage areas, coffee machines and milk foamers and slushie blenders, counters, floors, drive-through windows, dumpsters, a loading area, office space, and so on. Land border crossings will include facilities at booths, desks, scanning machines, loading docks, and other parking areas at which interviews and inspections can be conducted, offices, rest areas, roads and sidewalks and other paved areas, greenery and and runoff collection areas, and signage, crossing gates, turnstiles, and traffic lights to control the movement of vehicles and people.
• Physical Equipment — Computing: Many types of computing devices are used for different operations. Sensors, actuators, indicators, and displays can be attached to those. A Starbucks, for example, will have all of the computing equipment needed to communicate with the home office, track finances and stock levels, process online orders, and manage customer cash balances and loyalty points. A manufacturing plant will include sensors and actuators to track storage quantities and measure and control movements and operating settings. Controls and displays allow users, operators, and customers to interact with and understand the processes.
• Operating Systems: Many computing devices will include operating systems of various types and complexities.
• Communication Channels: Messages may be passed between entities of all kinds. They may be physical, in the form of documents; electronic, using different, agreed-upon information protocols across different types of physical connections; visual, in the form of lights and signs and arrows; and audial, via alarms, warbles, and spoken announcements and instructions.
• Implementation Languages: Computing systems will be implemented in different programming languages, each of which have different feature, involve different trade-offs, and are suited to different purposes. I go into more detail here.
• Algorithms and Calculations: Calculations are performed and decisions are made based on an infinite variety of considerations and methodologies. Ready-made methods and techniques can be applied in many cases, perhaps adjusted for individual situations, but in other cases they must be developed from scratch.
• Data: Data drives every process and even governs the development of discrete products. I discuss data in many contexts here, here, and here), just for starters.
• UI/UX: User interfaces and the user experience come in many forms. An entire field of study has grown up around the design and implementation of these in different forms. Screen-based displays are an obvious (and ubiquitous) form of interface, but they aren’t the only ones. Many types of control, feedback, and situational awareness are made possible though every kind of device imaginable. (Also see the discussion of communication channels just above). These require every bit as much consideration, analysis, and design as screen-based interfaces do. Just think about how carefully designed the controls of automobiles and standup arcade games are, and how much research and experience has gone into creating them. Now consider the controls of a nuclear power plant, as shown in this still from the movie The China Syndrome. (I spent a few years developing and implementing thermo-hydraulic models for training simulators with control panels that looked like this, and I can tell you these things aren’t designed casually.)



• Security: The field of cybersecurity is exploding these days but security considerations occur in many additional situations. Banks and prisons involve a high degree of security, as do schools, corporate methods and information, personally identifiable information associated with medical and financial data, transportation, hazardous materials, and infrastructure. Security is a critical aspect of military operations, and even of competitive sports. A major point of weakness involves the behavior of the human participants and (would-be) guardians of secure processes.

Target Industry

Industry knowledge is always important. While the skills and insights from all the other sections of this article can be applied to any new situation, having knowledge of the methods and history of the industry at hand is usually useful. This knowledge acts as a form of shorthand for communication with other practitioners and stakeholders, and can also act as a shortcut to understanding the best way to look for solutions. That said, industry knowledge can also act as a limitation on the types of analyses performed, by constraining what investigators may be willing to consider. Applying techniques and solutions from other fields can be an important source of creativity and lead to meaningful improvements.

• Processes: When I first started working as a process engineer in the paper industry, I had to learn a ton about the craft and techniques for making paper. The industry had a unique set of parameters for describing the physical characteristics of paper, of which our company used about twenty. I not only had to learn what those were but also how the various pieces of equipment and chemical processes would change them from one step in the production process to another. I further had to learn the combinations of characteristics and processes that resulted in different types and grades of paper (consider the differences between bathroom tissue and newsprint, only as one example). This exemplifies an easy-to-understand physical process, but the same tradecraft and understanding applies to businesses of all kinds. The field of accounting (and financial analysis more generally) has its own rules, techniques, traditions, and regulations (think GAAP, or Generally Accepted Accounting Principles). The field of insurance (and actuarial studies) has a whole different oeuvre.
• Equipment: Each industry has its characteristic types of equipment, while other types are widespread. Think of the different kinds of machines and process elements you might find in any manufacturing plant. Some will be general, like drills, CNC milling machines, heat exchangers, pumps, valves, pipes, and conveyors, and hydraulic presses, while others may be unique to an industry, like looms for textiles, thermo-mechanical refiners for paper, nuclear reactor cores for power plants, and so on. Start by knowing what is already available; continue by understanding the parameters governing their design, acquisition, emplacement, operation, and maintenance; and end by knowing when you may need to employ something creative and new.
• Sources and Sinks (Inputs and Outputs, Suppliers and Customers): Understanding the inputs and outputs of any process is indispensable. Inputs and outputs take the form of people and organizations as suppliers, customers, stakeholders, researchers, and regulators. They also take the form of raw materials, intermediate goods, and final outputs — and every kind of information imaginable.
• Standards and Measures: Every field has its characteristic measures and metrics. Many are just common units of measure from various areas of physics, but others are more specific. Many are derived from large volumes of data, vary widely depending on what is included, and inspire vigorous, ongoing debate. The Federal Reserve, for instance, publishes (or at least used to, I think some may have been discontinued) six different measures of the money supply (named, super creatively, M1 through M6), but additional measures are defined by other groups (e.g., the Austrian True Money Supply). The measure of monetary inflation is even more contentious. My favorite measures come from the paper industry (as described in the Processes item, above). My favorite measure of all time is Canadian Standard Freeness, which essentially describes how long it takes for a pulp sample to drain under very specific conditions. Other metrics and KPIs (Key Performance Indicators) are generated by specific organizations for their own custom uses, often derived from a number of other factors. Those KPIs or MOEs (Measures of Effectiveness) may be expressed as fixed values (six or less rejected parts per million) or as probability values (customers must be served within fifteen minutes, eight-five percent of the time).
• Regulations: These regulations may be set by government, industry trade groups, or independent testing entities (e.g., UL Labs). However, it should not be assumed that the existence of regulations and regulatory bodies yields optimal or even desired results. It should further not be assumed that the establishment of said regulations is the cause of any positive trends or outcomes.
• Participants and Competitors: I worked in a couple of industries where there were only a handful of competitors. For example, I think there may only have been three companies in the world that made thermo-mechanical pulping refiners in 1989. I think only three companies made nuclear power plant simulators, as well. The universe of customers was larger but is also constantly changing. Most of the work I did in 1989 involved the production of newsprint, but with the decline of daily newspapers, that market has contracted significantly in favor of cardboard packaging stock. Knowing who the competitors are, who they serve, and how things are changing is an ongoing challenge. It is also important to understand which individuals are the important business, research, and thought leaders in any field.
• Trends: As noted above, things have a tendency to change. Understanding how and why is important. Being able to spot potential changes before others provides the best chance to mitigate or avoid threats and capitalize on opportunities ahead of any competitors.

Engagement Methodologies

As business analysts, project managers, sponsors, and other participants, we should have a good idea how to attack problems individually and, more often, in groups. Many of the same issues come up and many of the same skills and training are required to create effective solutions and realize value. These are common to almost any type of endeavor.

• How To Run an Engagement: I have served in almost every role in a wide variety of situations, organizations, industries, and types. I have created my analysis and solution framework as the result of those long and varied experiences. Many of those involved my own successes and failures, but I learned a ton from what my employer and customer organizations and their people did well and poorly. I write separately about business analysis and project management below, and my framework primarily concentrates on the business analysis and solution creation, evaluation, and selection process, but in the larger scope of things I always think about how the two work hand in hand. Knowing how to set up an engagement and work through it in an organized way is invaluable.
• How to Derive Value: Even though the phases of my framework are always the same, different individuals and teams can find themselves effectively working in, modifying, or preparing for work in any phase at any time, and at any level. It is not uncommon for work to be going on in all phases at the same time. The value of my framework is that it enhances the situational awareness of the participants, so they have a solid context for whatever it is they’re doing and can communicate it clearly to others. More importantly, working through the phases can lead to deriving value based on many possible types of solutions and opportunities. The opportunities identified may be by phase or by approach.
• Business Analysis Skills: The practice of business analysis involves analyzing problems and developing solutions. It is detailed in two major handbooks. The BABOK (Business Analysis Body of Knowledge), published by the IIBA (International Institute of Business Analysis), details the practice from many points of view. It provides a framework similar to, but structured differently from mine, describes a list of fifty techniques, and provides other contexts and information for practitioners from beginner to experienced professional. The IIBA also sponsors numerous certifications in the subject. The PMI, described below, also offers a thick handbook and certification for business analysis.
• Project Management Skills: The practice of project management involves setting up an environment and acquiring and managing the resources needed to solve a problem. As noted (and linked) above, project management may be thought of as a wrapper around the work of business analysis. The PMBOK (Project Management Body of Knowledge), published by the PMI (Project Management Institute), details the practice from many points of view.
• Participants and Stakeholders: I include an item called participants and competitors above, which is mostly about the organizations and thought leaders. Here I think more in terms of individual practitioners and those associated with and affected by their work. Business analysis recognizes many different stakeholder roles (the BABOK lists business analyst, customer, domain SME, end user, implementation SME, operational support, project manager, regulator, sponsor, supplier, and tester while recognizing that other roles exist and that individuals may serve in more than one role). Many additional roles may exist, though many may fall into one of the two listed groups of SMEs.
• Financial Analysis: Financial considerations are often involved in business analysis and project management. This can involve calculations like ROI, payback period, the time value of money, and all kinds of estimations, compilations, and accountings of prices and units.
• Tradespace Analysis: Life is a constrained optimization problem. You never have enough of all the resources you want. Money is an important constraint but, believe it or not, the more onerous for us humans is ultimately time. The classic tradeoff is among the Iron Triangle constraints of time, cost, and quality (or features). The joke is that you can have it fast, cheap or good — pick two! (And if you want it really, really fast, cheap, or good, pick one.) However, an infinite number of other tradeoffs are possible. Consider the cost of computer time to support a programming language that does a lot for you and allows for faster development with fewer errors, contrasted with one that runs faster and uses fewer resources but takes longer to develop in and is more prone to errors. Labor vs. automation is another common tradeoff.
• Technologies and Tools: These can involve all kinds of software (for word processing, spreadsheets, media, collaboration) and analytical techniques (statistics, optimization, marketing, simulation).

Everything Else

In the end, working on projects and developing solutions for internal and external customers is about working with and serving people. You also develop your own skills, abilities, and reach, but hopefully that is applied to the first goal.

• Communication and Empathy: Working with people well means caring about them and correctly understanding their needs and supporting them so they can make their best contributions. Many analysts are more thing-centered than people-centered, so this can be a struggle, but keep at it. It is the most valuable and rewarding ability and gift you can have.
• Ability to See Connections and Commonalities: These abilities are major aspects of creativity. Another major aspect is the ability to put things together in new combinations in ways that make sense for that effort. I write about seeing and finding connections and commonalities in detail here. Like getting better at communication, these skills can be developed if they don’t come to you naturally.
• How to Learn Anything: Last but not least, you should be willing to learn everything and anything. Every project will require you to learn its unique particulars and requirements, but as all the previous descriptions attest, there’s a lot more. You don’t have to become an expert in all this stuff, but you should at least know that it exists, so you can find the right people who do know and communicate with openness and respect.

Can you think of anything else it might be valuable to know before starting a project? I’d love to hear about it.