(Originally posted on SVProjectManagement.com)
I’m delighted to post this story on behalf of Emily, who sent it to me as evidence that she was becoming more scrappy. In this story Emily shows us how we can help our teams think things through and clarify goals by asking good questions and facilitating discussions that people are “too busy” to have without our influence. It can take courage to schedule a meeting when people feel they have “real work” to do. But – done right – meetings ARE real work. Read and learn from Emily’s courageous leadership! – Kimberly Wiefling, Author,Scrappy Project Management
GUEST POST by Emily Hennessee, Business Analyst & Project Coordinator, LightSpeed Technology
One of the bad habits I’ve developed that stems, I believe, from not having any formal technical training, and yet being responsible for managing software development projects, is that I sometimes tend to not ask enough questions to my team. In particular, I tend not to ask questions about exactly how they envision changes will look below the surface, or user interface, during the planning phase of our major projects. I almost always have a very clear picture of the high level product, and I’m able to draw diagrams of what it needs to end up looking like to the user. But when they hear the requirements and say, “Okay, all we need to do is A, B, and C.”, and all A, B, and C are all foreign languages to me (or maybe they are familiar but I can’t visualize the mechanics of it) I sometimes assume that they know what they’re talking about, and I’m the only one who doesn’t get it. So I don’t ask. They’re doing the work, so I figure that as long as they “get” it, we’re good. Now I will say I’m not ALWAYS that bad, but even occasionally is too often.
Part of what causes this is time constraints, but I’ve learned that this is no excuse in a scrappy project world. So yesterday I organized a call to discuss a project to implement an error checking and notification system on 3 of our major processes. It was a particularly complex discussion around writing events to an SQL table and determining the base units of items we were going to measure for each process. Needless to say I hit a few technical road blocks in my understanding during the discussions, but I’m proud to say that I put my foot down and demanded plain English answers. The call lasted a total of 3 hours, because the more I asked, the more ideas started to pop into my team members heads about alternatives and additional features. The good news is that we all walked away with a very thorough understanding of how we wanted this system to work and look. The bad news is, we’re not sure right now if we have the resources and time to make the ideal set of changes (to redo a much larger process as part of this effort). BUT . . . at least we’re not diving in head first into a project with false expectations and unclear requirements, which is something we do far too often around here.
So, a small victory for me!
Business Analyst & Project Coordinator
LightSpeed Technology Groupby