We just wrapped up a project using Hansoft for agile project management here at Experiment 7. Given that I have a weird obsession with project management information systems, I found myself wanting to write up some notes on that process and share it with my fellow game developers. 

Key Takeaways

Here’s a quick tl;dr, so you can decide if you want to invest time in the article. 

While many of these learnings can be mapped to any project management system, I did want to focus on the Hansoft-specific side of things.

Caveat: I’m Totally Biased

I’ve been using Hansoft since preproduction on Homefront, about 10 years ago. Since then, I’ve used Hansoft to ship 15 games at 3 companies (Kaos, Slingo, Experiment 7) and spent more hours than I care to think about in the local client. My proficiency with the software is such that I’ve made our TD nauseous during a screenshare because I was clicking through menus and dashboards too fast (felt better about that one than I should have).

I say this not to humblebrag, but to provide some context for why I’m such a Hansoft cheerleader. I’m like anyone else who has a vested interest in working with a software package that they really like and have a ton of familiarity with. I like this software and I love to nerd out about it.

Please don’t consider this write-up an objective dissertation on the strengths or weaknesses of the software. I have deep inborn bias and I’m not trying to tease it out of this blog post. I hope it will be useful for those folks interested in learning more about working with Hansoft (or our specific flavor of agile methodology at Experiment 7), but for a more broad-based assessment of project management systems in general, I would look to the many great comparative articles on the subject.

1. Fill out everything – Work ‘The Hansoft Way’

Hansoft is a powerful tool, but it’s not as flexible as other web-based solutions. That’s simply the tradeoff you make when you use a robust client-based project management system.

Accordingly, my single biggest piece of advice for working with Hansoft is to work with it the way the system is designed (aka The Hansoft Way). You’ll be tempted to fiddle with this little workflow or change this custom field over here, but the bottom line is that the entire system is built with sub-system synergy in mind. Don’t try to change Hansoft – work with the established paradigms built into the program.

Dashboards depend on complete data to inform the team. Releases depend on a finely groomed backlog to project completion dates. Burndowns require honest daily estimate updates to create accurate velocity reports. 

The downside is that this makes Hansoft a more time-intensive, high-touch project management system. If you have a very small team or your primary project manager has a lot of responsibility outside of projections and time analysis, this may not be possible. 

However, the upside is that forced thoroughness means that you’ll have a robust data set and industry-best projections at your fingertips, displayed in a format that is easily digestible for stakeholders and team members alike. 

2. Update estimates and statuses in real-time during standup

Traditionally, I’ve been of the mindset that standups should be focused almost exclusively on identifying and resolving roadblocks, opening lines of communication, and flagging conversations that need to happen. When Demetri Detsaridis (our Managing Director) recommended we update our time remaining estimates in real-time during standups, I was initially resistant to the idea, on the grounds of keeping focused on the priorities above (and because I had done it the other way previously and we scrum master types are creatures of habit).

However, after I agreed to test it out for a sprint or two, I immediately found there to be some great benefits, both obvious and subtle. 

On the obvious side, having everyone update their hours in real-time ensured that task estimates were incrementally updated every day with 100% consistency, providing much more granular historical data. Additionally, providing those updates at the same time every day created a natural check-in time for key stakeholders to review dashboards and sprint burndowns with greatest accuracy (as opposed to previously, where updates happened throughout the day). 

On the more subtle side, adding time estimate reviews to our standups made the team more cognizant of our schedule, velocity and risk profile, which is every project manager’s dream come true! Giving the team visibility and focus into their own time estimates and those of other members of the sprint team creates an internalized understanding of the roadmap, giving everyone on the team intrinsic buy-in (as opposed to the less meaningful extrinsic buy-in created by a producer nagging everyone about deadlines and estimate updates).

3. Use Dashboards for self-serve project management 

With better, more granular estimates in place, Hansoft Dashboards become a great place to communicate project status, risk and opportunity both to key stakeholders and to the team itself. 

While some folks consider visualization of this data to be a lower priority task, if the team isn’t drawn in by the visualization, they won’t be interested in the data behind it. Creating a compelling visualization of the project itself is absolutely mission critical, and this is one area where Hansoft really shines.

In terms of information presented, Hansoft exposes a ton of data to project managers. While it can be daunting to dig through everything at hand, once you have the templates created, you can go a long way towards informing the team. In terms of style, Hansoft provides simple schemes that help you get nice results with minimal work. 

These are a few samplings of presentations to the team, which brings us to our next topic… 

4. Pull information out of Hansoft and into meetings 

Not everyone loves digging through Hansoft and finding important data about the project (Ridiculous! I know!). While this might seem obvious to an artist or engineer, this can be somewhat hard to grok for project managers for whom Hansoft has been an extension of their thought process. 

This is a simple lesson, but an important one. The more you can pull data out of Hansoft and bring it into your staff and status meetings, the better. While a certain percentage of your team (those with project management data fetishes) will gleefully dig into the many nooks and nested menus of Hansoft, the rest won’t and will miss out on critical context for why the work they’re doing is important, why the deadlines they’re working towards are critical and where the project is on the whole. 

For that latter group, be sure that your milestone, sprint and velocity data is presented regularly in a compelling way.

5. Hit up the Hansoft support team

I’m horrible at this. If I see a problem, my first reaction is often to bang my head against it, get frustrated, and then rage-eat something full of carbs. This is not terribly productive and while it often leads you to solutions to other problems you’re working on, when you have a specific task at hand, it is not the most effective way to get things done. 

What is productive, especially when working with Hansoft (it’s a big ass program), is hitting up their support team. They’re super reactive and many of them are project managers themselves, so they have their favorite tricks and hacks ready for the problem you’re struggling with. 

Support [at] hansoft.com. Seriously. Do it.

6. Do bug tracking in Hansoft. It's great.

This is a moderately contentious point. I’ve spoken to a number of QA managers who don’t love working in Hansoft, and who prefer web-based solutions for broad-based testing. I think this is bunk.

Maybe in an earlier version, where bug tracking and task tracking existed in separate databases, I could see why one wouldn’t want to use Hansoft for bug tracking. However, with later versions, it’s a great tool for QA. Since it’s a local client, you can enter bugs much faster (type tab type) than most web-based systems (type click type), QA accounts are free, and since you can bring bugs over to the sprint itself, there’s no reason not to do QA in Hansoft. 

7. Backup Hansoft in Dropbox/Drive

This is a bit of a minor/operational point, but I’ve experienced catastrophic data loss with Hansoft and it was horrible. Short version: we had a regular server backup that literally burned up in a fire. Our offsite backup backup was corrupted. Our backup backup backup was months old. We lost literally months of historical data, including our meticulously-groomed backlog, and a ton of user stories. 

I was not a happy producer that day.

For Experiment 7, we hosted our Hansoft server on my machine at the office (the Nomad WeWork has ungodly fast internet), hooked up to a static IP, and just pointed the file system and backup process to a folder in our corporate Dropbox instance. While this means that my machine is almost constantly syncing data, it’s all so small and our machines are so beefy that it doesn’t even register as a blip on the radar in terms of processing power or network bandwidth. 

The upshot is that we have all of our data safely tucked away on Dropbox’s servers. As someone who has literally been burned by catastrophic Hansoft data loss, I can’t recommend the approach enough. There’s another burndown pun to be made here but I don’t know if Hans would approve.

Closing Thoughts

The bottom line is that Hansoft is a powerful tool that if used correctly can be the backbone of your organizational efforts. It's a client-based, fully feature solution though, so be ready to invest time in it. If you're looking for a lightweight solution, Hansoft makes a product called Favro, or there are plenty of other lightweight Trello-style project management systems out there. 

If you're like me and prefer a spreadsheet-based, Microsoft Project-but-better solution, Hansoft classic flavor is a great option.

-----------------------------------------------------------------------------------------------------------------------------

Thanks for reading! If you’ve made it this far, you clearly share my sickness for overthinking PMIS software. You should probably add me on LinkedIn so we can hang at GDC or follow me on Twitter because that’s what we do these days, right?

As a next step, what project management system do you use? I’d love for folks to hop into the comments and get a conversation going! I always enjoy hearing about how other people manage their projects and argue with them about how I’m right and they’re wrong discuss the relative merits of each system.

Coray Seifert is the Director of Production for Experiment 7, a VR strategy game developer based in New York City and San Diego. For more than 15 years, Coray has developed games as a producer, game designer, and writer for organizations like Autodesk, THQ's Kaos Studios, and the US Department of Defense. A Lifetime Member of the International Game Developers Association, Coray was elected to the IGDA’s Board of directors in 2007 at the age of 27; the youngest board member in IGDA history.