Ongoing Investigations

Tag: project management

  • Drafting a Scope of Work

    This past week I had cause to make a scope of work for a client from scratch, which is something I don’t get to do very often. I figured I could blog the process just to document it, though I’m not going to share any examples from the actual SOW I made — just outlines.

    I actually had a scope of work that I’d made back in 2022 (!) available in Google Drive, which I only remembered existed by coincidence. But it was a nice find, because it meant that I could reuse all of the formatting work I’d done previously, even if all the content had to be jettisoned. I could also build off the structure of the old one/scrap or add parts as needed.

    The overall structure was:

    • Title
    • Contextual information
      • the client’s institution
      • the name & title of the person I’m preparing it for
      • my name & title
      • the date
    • Overview (context section that goes sort of broadest to narrowest on detail – the name of the product/service and what the client’s needs are, then info on the product/service and how it will meet those needs)
    • Work Breakdown (specific steps that will happen in order to provide the product/service – both what we’re responsible for & what the client will need to do)
      • If I need to give a specific explanation of why a step has to happen a certain way, I’ll do it here, but I try to keep it short
      • Mode of delivery, if there’s specific deliverables
      • Hours required for a service, if a certain step needs it
      • This bit got split into multiple sections for the SOW I made, because there were multiple things the client wanted & each one had different things that needed to happen
    • Costs Breakdown (a table of costs with the following columns):
      • Unit type
      • # of units
      • Item/description
      • Unit price
      • Total item price

    In other SOWs I could probably include a specific work timeline or relevant history between Reclaim and the client, or other information if it’s needed, but it wasn’t for this.

    The other important thing was a sanity check. I ran this by Taylor, Amanda and Jim, and they noticed some big changes that needed making (Taylor in particular found a point where I was seriously overcomplicating things!)

    I found the process pretty fun! Drafting this kind of thing from scratch doesn’t come up all that much, but somehow it feels like helping to create something totally new, which is just plain cool.

  • Planning with Omeka S

    Over the course of the next month or so, we’ll be developing an Omeka S site to host translations of medieval documents — which means we need to know how Omeka S works. Today (and over the course of the next week or so) I’m taking a dive into Omeka S’s documentation in order to prep. The documentation is available here, in case you were curious.

    I won’t rehash it, because explaining a lot of the technical stuff will get boring fast, but the main takeaways of the beginning are much more geared towards questions of design and planning than specific fiddly technical bits. So that’s what I’ve been thinking about in the context of our project. They’re good questions to ask of any project, but I’m going to answer them here specifically for what we’re doing, because… yeah.

    Who is our audience? Primary, or secondary? Our primary audience will be historians who want to reference medieval documents; our secondary audience, if we decide to make this part of the project, might be translators looking to share their work. That’ll need to be another conversation.

    What do we want people to be able to do on our site? The site’s primary concept is as a searchable repository: we want people to be able to locate useful documents based on the metadata associated with them. That means we don’t need many pages of context, beyond perhaps a description of the project; the scholarship being done is in the presence of the content. The open-ended issue here relates to the first question: do we want translators to be able to share their work? That’s functionality we can add… but is it functionality we need?

    How are we thinking about what’s on our site? Omeka S operates using items, which have properties (metadata…ish?) associated with them; the items can be grouped into item sets, which also have properties. Items, item sets, and media can be used as properties for other items and item sets.

    This is probably the blurriest part right now. Each translation will almost definitely be its own item, but what will the core theme of each item set be – if we even have item sets? Will we end up making other features of the translations items, in order to create a better network through properties? (IE, if we have multiple translations from the same author, should we make the author also an item, so that we can navigate from the translation to the author to other translations?)

    This would be a question to answer before we get started, since it would inform everything about how we enter the data. It’s not a bad idea, but scope creep is… not something to take lightly, and we need to do some time estimations.

    Goals for planning, then:

    • Plan out our rough stages (given what we need the site to do, what do we build first? When/how do we add the translations, and how do we store them?)
    • Ballpark the amount of time each stage might take
    • Figure out who should be doing what, depending on the amount of time we have, what our deadlines are, and who’s busy when
    • And of course, keep reading the documentation

  • Writing Documentation

    The title really says it all: that’s what I’ve been up to recently.

    So, yes — coding, VR and AR development, learning Unity — it’s all taken a bit of a backseat in an attempt to get some more time consuming and generally relevant tasks taken care of. We’ve solved an issue with some web addresses that were bouncing, posts have been migrated from one site to another, but there are still general logistics for the migration going on.

    The first is just… making sure there’s general useful documentation for our sites. Our setup is a bit unique, so the current documentation isn’t really what we need, and in any case it focuses a lot more on the general set up than the day-to-day tasks.

    The second is tracking our sites. We have a lot of sites installed, but some of those sites have subsites (not included in the installation count), and other sites are HTML-based and therefore not installations (and therefore, uncounted). I’ve been going through each subdomain and tallying up each site, trying to figure out who’s responsible for what and why.

    Writing up documentation is a lot more fun than I thought it would be. Thinking through where I’ve run into challenges vs. where others might have issues, and what’s easy to miss but very important… it’s an interesting puzzle. I’m enjoying the process of it. Part of it may also be that I just like writing, and documentation is a good way to keep my hand in. Site tracking is a lot more data entry, so it’s less stimulating, but an audiobook or a podcast in the background keeps my ears going while my brain stays on task.

    I’ve been trying out Instagantt, an organizational tool someone else on my team recommended. So far… extremely mixed results.

    There’s nothing wrong with the tool itself or any of its features. I like what bits of it I get the chance to use. It’s easy to add tasks, I like the way it tracks tasks and subtasks, marking off tasks is satisfying, it keeps track of lots of information, it’s supposed to be very good for team collaboration…

    Except I inevitably cannot keep the page loaded for more than forty-five seconds to a minute without it freezing.

    I tested it in multiple browsers. Firefox catches the issue faster than Chrome, but it’s there in both. My only thought right now is that it might be a Windows compatibility issue, but that would be extremely weird for a team product.

    I want it to work. I really do. It’s much, much better than my Google Sheets Gantt charts — or it would be, if I could use it.

  • What Do I Need (In Order) to Learn?

    Alas, my hopes for the Agile tutorial were for naught: the sections on Scrum, Extreme Programming, and Kanban were all explanations of the mindset and values behind each practice, without much explanation or examples of the actual process. Part of it might have just been that they were too wide in scope, but I came away feeling more like I’d been listening to an extremely redundant sales pitch than a demonstration. There’s some interesting reframing of concepts, but otherwise…

    It does have me thinking, however, about online education, since LinkedIn Learning tutorials have been around since way before the pandemic (though they used to be called Lynda back when I was a freshman). Why have some of the courses I’ve taken been effective, and others haven’t?

    Different courses I’ve taken (that I remember) include: this Agile Foundations tutorial, an introductory course on project management, and a lot of small one-off lessons on video editing for various CAMS classes.

    The Agile tutorial had only two practices which it explained in clear detail, with visual aids: the swim lane diagram (a board with organizational sticky notes which showed up in both a general process explanation, and in the Kanban unit) and a game called Planning Poker, where each person individually estimates the amount of effort it will take for the team to complete a task, reveals their guesses, and then discusses why they thought that. There weren’t any exercises to prompt engagement, and there were a lot of issues with redundancy, repetitively unclear terminology, and overlapping concepts (one phrase that came up all the time was something like “Now, <this term> is a term from Scrum, and I use it because Scrum is one of the most popular Agile frameworks, but you don’t need to use this term, you could say something else”… even though Scrum and its terminology were part of the second-to-last unit in the video, so I had no clue what was going on).

    The introductory PM course had very little to do with mindset or philosophy, and a lot to do with practices. It also asked for engagement in a way I thought was very effective. The broad-strokes outline of the course was to write down everything that had to get done on sticky notes, create a flow-chart with the sticky notes of what had to get done when, estimate times and costs, and turn it all into an actionable chart. The videos made a point of saying “Pick a project you want to do, and then do all the steps with us as we go”, which made it easy to be invested in what you were doing and follow along, but you couldn’t pick up any individual part as a lesson.

    The one-off lessons were extremely hard to be invested in. They were part of larger courses that had exercise files for you to follow along with, so that you could edit stock footage and audio and see clearly what the instructor was doing, but this also meant that you didn’t really care about the project. They worked well for two- or three-minute tutorials, which was all we needed them for, but I don’t think I could see myself willingly sitting through a full course.

    These all seem like pretty obvious statements — actionable information > vagueness, emotional buy-in > boring exercises — but I’m hoping I can use this for self-teaching and for thinking about different disciplines. Some disciplines are very actionable, but hard to personalize; some can appeal to personal goals, causes or interests, but be sort of vague in their application. I need better, different strategies for each.

  • ‘2D Game Kit’: Day 2 (& Other Projects in the Pipeline)

    Went through the back half of the 2D Game Kit (teleporting to another scene, and the video walkthrough). The video walkthrough was interesting — about half of it was information that had been covered partially or completely in the written tutorial, another 25% was inferrable, and the rest was basically new. For example respectively: monsters and how to fight/mod them; the fact that you can set up damageable obstacles and break down objects in your path (the written tutorial only covered damaging monsters, but it works the same way); and how to add items to your inventory and trigger dialogue popups. Still, I don’t think the redundancies were a bad thing, since working through a tutorial by yourself and having a game designer talk through her thought process both lay out two different and useful perspectives. Also, one noted difference between the 2D Game Kit and the Kart modding tutorial – the 2D Game Kit came with a lot of art assets, which I couldn’t change the color or look of easily. In the Kart mods, it was pretty simple to adjust the albedo on any given asset, which weren’t usually art/images.

    Other plans today: get a jump on “Getting Started with Unity”, and maybe look into some project management frameworks I’m not familiar with (specifically, Agile). The Getting Started tutorial looks like it’ll have some redundancies for me — I already worked through go-kart modding, I’ve tooled around a bit with the FPS intro project, and I have at least passing familiarity with the Unity editor by now — but there may be some new tidbits.

    Re: Agile, I’m passing familiar with the concept, but I don’t have a lot of experience with how to apply it properly. What I’m hoping is for better information on how to set up those sorts of recurring, multi-step processes (or whether Gantt charts can be extended easily and intuitively into an Agile framework, because I like Gantt charts a lot).

    This’ll teach me to look ahead — I started poking through “Getting Started with Unity” and it turned out that a lot of it was geared specifically towards the sorts of streams I already worked through with ‘Your First Game Jam’! I’m now wondering whether to work through the FPS and platformer exercises, though I’m planning to skip the kart modding section… but maybe it would be more worth it to move on to a different tutorial?

    As for Agile, I ended up going through a LinkedIn Learning tutorial on “Agile Foundations” that has been pretty disappointing so far. There’s some good information about Agile’s values and mindset, but most of it is evangelizing. I’m hoping there will be more actionable information later on, in the section devoted to Scrum, Kanban, and something called Extreme Programming (!).

    Overall, a pretty scattered day, but I feel like I at least got information I can use in a couple different areas.

css.php