Are You a Project or Development Manager?
If you’re working in the capacity of managing projects – whether they’re development or database or… whatever type of IT project you may be involved with, there are a few suggestions and ideas to consider as you go along.
First, as mentioned yesterday, (read more here) begin with the end (user) in mind. I can’t stress this enough. Yes, it’s a pain in the backside, frankly, to involve those that will be using and getting information from your new system. Yes, it surely adds time. It can lead to a whole slew of time-wasting meetings too. But… (you knew it was coming) you will absolutely make it up in time saved having to rebuild your project, re-design your project for just ONE of the surprise things you’ll learn in these end-user conversations.
I can’t think of a single time when I’ve worked with end-users over the course of getitng a project going where it didn’t pay off to know what they needed and expected. Not one time. Sure, not every meeting or idea is productive, but I guarantee you that one "lightbulb" discovery that you have will save you more than it takes.
Second, question your team about what they plan to do to address requirements and why they think that will do the trick. This is just a good brainstorming round where you can make sure you are thinking it through and addressing the issues at hand. This is a technical step, not a requirements step. There are so many times when this produces surprises in "well, I thought I would do this…" ending up with "What?!? Why do it that way? It’s easier to do this other way!" Save yourself the redesign or less-than-optimal design.
Last, some items to make sure you’re including:
– Technology that will be used (and what platforms will it be used against?)
– Access and security requirements
– Performance requirements (includes things like up-time requirements and downtime allowances)
– Output requirements (reporting, querying tools, BI-type tool access)
– Compliance requirements – PCI, others – make sure you know what applies
– Interaction with other systems
– Who’s going to sign off, and what are the requirements to get that sign-off?
– Who’s going to determine changes, scope modifications, schedule changes?
There are more, but we’ll get into those in the future. Take a minute, think it through – I think everyone does that, but also work with your team and stakeholders. You’ll be glad you did.
So, what did I miss? Drop me a note (swynk@sswug.org) or comment below…