Some of the people reading this know me, and know me well enough to know that I have been recently pursuing some education and certification in the field of Business Analysis.

At the other end of this road for me lays a certificate that says that I can think big picture thoughts about systems and people and processes and technology and organizations and then write those down into neat and tidy documents—and then hopefully get paid for that. 

*wink wink if you’re reading this.

In the meantime, I am writing an indie game in Rust and Bevy and blogging those big picture (and often small picture) thoughts about the systems and people and processes and technology and organizations involved in turning thousands of lines of cryptic computer instruction into a toy in the form of a virtual science fictional supermarket.

We’ve all got our quirks, huh?

The overlap between my two efforts is probably not coincidental.

I have been doing all sorts of real work over the last couple decades that, while not strictly capital-BA Business Analysis, has been in the realm of doing the things that business analysts do to accomplish the things that business analysts accomplish with the goal of creating projects, supporting volunteer gigs, or (as it turns out out) scoping out my own learning and side projects. 

As I sat in the most recent of my courses with a room full of people talking about business analysis-kinda things, my mind started drifting back to the effort I had made leading into and throughout this very Pleck’s Mart game project.

I mean, just for starts, I’ve been running it like a project.  I have a capital-P project set up in GitHub, for example, with actual Milestones and Issues and Timelines and a Board on which to view it all.  (But then, that’s all more of the project management stuff and you clicked over here for the business analysis stuff.)

Thus, this all leads to the question: how did I get from dabbling in some code in my basement on a chilly December morning to sitting in Starbucks legitimately considering a plan that brings me up to and beyond releasing a game on Steam in the next year.

Business analysis, as it turns out and broadly speaking of course is a lot about understanding a problem in the current state and doing a lot of work to make a plan to bring you to a future state. 

My current state (back in December):

• I suddenly had some spare time on my hands.
• I had been working on some scattered ideas for a game on paper for a while, but had no vision for how to turn that idea into real pixels on a screen.
• I didn’t know any game-coding-type computer languages or libraries well enough to try this big idea, did I?

In the broad sense of things, me as a creatively-inclined guy had the problem of having a big idea with few details or sufficient skills to achieve the fruition of said idea, but adequate time to address some of those deficiencies if I was focused and directed at the right things.

My future state was simpler, if challenging to achieve: having learned a computer language to a level of proficiency to design, build and support an indie game, I will have a game available to download from the internet for the public to enjoy.

So. What next?

Here there are a lot of things that a Business Analyst might do to assess those challenges. When one is working with multiple people or an organization this involves meetings and documents and surveys and digging into org charts to understand where the right people are to get the information squeezed into something resembling a plan.  For just little ole me, tho? This started out as basically some reflective writing and starting to plot things out.

Maybe a BA would dig into a SWOT analysis or do some functional decomposition on the current state to try and understand how things work.  For me, I sat in Starbucks and legitimately wrote about this. Reflective writing. Introspection. Personal brainstorming. Whatever you want to call it. You can probably read some of the early stuff that I posted in the archives of my blog. A lot of it was at a high level working to understand what tools I had in my belt (my strengths) or the things I still needed to figure out (my weaknesses) while putting it into the context of some of the resources and time I’d recently stumbled into (my opportunities) and the contrarian facts of tackling a dauntingly huge project on my own for which I had no real prior experience (my threats.)

Maybe, a BA might plod into the territory of looking for gaps.  In my own context, I have skills in multi-modal art and a bit of experience coding. I also have two hundred thousands words of contextual lore that I’ve written over the last year and that I can definitely use to support the world building I had imagined accompanied my future state game.  On the other hand, games need, for example, music and I’m no composer (gap) and games require extensive testing on multiple platforms and I have just one aging desktop computer that has never even heard of 4K resolution (another gap.)

So, at my Starbucks table with a GitHub project open and my writing tools at the ready, I did some informal requirements gathering with myself. 

• I needed a proof of concept. Could I code anything at all, let alone a relatively complex game? I’ve been scripting web code, but those legit-coding courses I took in University were a little dusty in my brain.
• I needed a small budget. I was likely going to need to pay for a few things along the way, from collaborators to technology to even (way down the road) a listing fee for hosting the game in a storefront.
• I needed a marketing plan. Indie games win or lose in the real world on word of mouth. Building something in isolation and posting just hoping for people to play  it is pretty much a recipe for failure. (Ahem, follow me on Substack or Bluesky!)
• I needed a schedule. I’m in the awesome position at the moment to treat this like a job. (I mean, if someone wants to chaaaaaange that, I’m cool with a conversation about it but…) I can’t just poke at this thing part time and expect to have a product inside of even a decade, let alone a year.

Simple enough, right?

All of this penultimately led to lots of words and a few contemplative walks in the woods and at the end of the day I was staring at that capital-P Project in GitHub that I mentioned earlier. I mean, I could have written all this up and formalized it, you know, put together a lovely slide deck to try and convince the guy at the top but by then I was already on board and was too busy sitting in my pajamas at the keyboard trying to animate some sprites or something to need another meeting about this.

Does this mean the Business Analyst hat has come off?  

Of course not. I mean, it is a bit of conceptualized silly fun to think about it all this way (particularly in the context of my educational and certification pursuits running parallel to all this) but there is a lesson buried inside, too. Just over one month into this effort I may still be a long way away from a finished project, but simultaneously I have a plan. I did the work. I put the pre-work into this thing of sitting down and plotting out not just what I was trying to accomplish, but how I would get there, what might get in my way, and some ideas to overcome the obstacles along the way.

I have a bright orange textbook sitting on my desk right now that outlines a vast collection itemizing and explaining all the tools and techniques that a business analyst needs to pry open something bigger and more complex (and more expensive) than a simple indie game project by some guy in his basement, and I could probably open that book to any random page and find something useful to enhance my efforts—and maybe I will. But my point, and the lesson here, is that as much as the code is important and interesting and a big part of what I’m doing, there is more going on than a man in his basement dabbling in being a keyboard cowboy.

And in as much, I think that has brought me as far as I have come thus far, and hopefully keeps me going forward.

Analysis and planning for the win. Achievement Unlocked!