21

I am a Software Engineer and over the past few years I have become the de-facto software project manager simply because there isn't one. So to keep our sanity in the R&D/Engineering department, customers have become accustomed to coming to me with their requests. I have no experience in this realm so it is my first time acting as a project manager for software projects. I have managed other things but not software.

So, how do you manage software projects and mark priorities? Requests come in at infrequent intervals so we very well could be working on something for someone else and then another person comes in with a "rush" job that needs working on. Is it easier to just say First Come, First Serve or is it the person with the most money?

Improve this question
3
  • 1
    check out this: programmers.stackexchange.com/questions/874/…
    – luis.espinal
    Commented Oct 23, 2010 at 12:43
  • 1
    and perhaps this as well : programmers.stackexchange.com/questions/3747/…
    – luis.espinal
    Commented Oct 23, 2010 at 12:43
  • 1
    I use Nancy Reagan's slogan: "Just say NO!" Seriously. Never commit to anything on the spot. That's one of the ways software engineers get into big trouble. It is very important to resist making casual commitments or even estimations of whether something is "hard" or "easy". Always defer the decision and then take some of excellent advice that will appear in the answers. Your reputation depends on being able to deliver your commitments-- and it will be degraded profoundly as soon as you make too many commitments.
    – Angelo
    Commented Nov 15, 2011 at 15:13

8 Answers 8

Reset to default
21

I've found that the more a customer complains about how urgent their request is, unless they are also a developer in their own right, it's usually a good sign that the request isn't urgent at all. One of my professors in college always used to tell us not to let the urgent interrupt the important.

I usually classify requests in this order (YMMV):

  1. Issues related to a recent upgrade or migration (most important).
  2. Security fixes.
  3. Broken functionality of the existing system.
  4. Broken functionality in RC and beta features.
  5. Paid feature requests.
  6. R&D feature requests from a large part of the user base.
  7. R&D feature requests from only one or two users.

This last one actually takes a lot more time because they tend to be those "urgent, I need it yesterday" requests. In reality, the user has rarely thought completely through what they actually need or how it will support their business model. Most often, these urgent requests, once delivered, end up being used once or twice and forgotten about. And once forgotten, they become an endless headache of security holes and unintended consequences.

Improve this answer
3
  • 3
    Your professor may want to climb down from the Ivory Tower one in awhile.
    – JeffO
    Commented Oct 22, 2010 at 20:24
  • 6
    What he meant was a lot of people let all the distractions that beg for our immediate attention keep us from focusing on those things that are truly important. This was some years ago, so his example was the telephone. Whenever he was meeting with a student, he placed his phone directly to voice mail. I found it an excellent statement of integrity and efficiency.
    – Michael J. Sabal
    Commented Oct 22, 2010 at 21:00
  • 4
    Whoah, paying customers get a lower priority than beta features ?
    – JBRWilkinson
    Commented Oct 23, 2010 at 21:41
12

I like Covey's principles:

  1. QI - Important and Urgent
  2. QII - Important but Not Urgent
  3. QIII - Not Important but Urgent
  4. QIV - Not Important and Not Urgent
Improve this answer
3
  • Where is that from?
    – Rook
    Commented Oct 23, 2010 at 12:52
  • First Things First (1994) is a self-help book written by Stephen Covey and A. Roger and Rebecca R. Merrill en.wikipedia.org/wiki/First_Things_First_%28book%29
    – Adamizer
    Commented Oct 25, 2010 at 13:26
  • @Rook - Also listed in Covey's 7 Habits of Highly Effective People. Great book.
    – Nemi
    Commented Oct 26, 2010 at 15:36
6
  1. Setup a feature/bug/request tracking system and have your customers/coworkers file tickets. If they don't file a ticket for it, you aren't doing it. Tickets must be detailed enough to be actionable and must specify an "urgency" ("I need it now" vs. "nice to have").
  2. Go through new tickets and carefully scope them. Enter the cost in the ticket in dollars, developers, resources, and/or time. This is essential. When your customers see what something will really cost them, you'll see very different choices in the "urgency" field.
  3. On a daily basis, figure out your schedule based on the tickets filed & their urgency. Make the schedule visible to others so it's obvious what you're up to and your availability for future requests.
Improve this answer
1
  • +1 for the issue tracking. I've had to do this w/ co-workers before. I tell them if it's really that important for me to do, it must be worth the 5-10 minutes it would take them to file a ticket.
    – GSto
    Commented Oct 26, 2010 at 16:31
3

I've seen projects where requirements changes are managed by a very heavyweight change control system. This is bad. Many important changes do not happen because the customer does not want to go through the hassle of submitting a change control, so the software doesn't match their needs. Some small changes get slipped in "under the radar" to avoid the process, so the software doesn't even match what you think it does.

Conversely, I've also seen projects where the project manager thinks "reactive" means getting the coders to respond to every request from the users, which just means you never get any core development done and your code becomes a big unwieldy mess of hack atop hack. Essentially you now don't have any developers, you have a team of overqualified sales engineers.

So one might hope there's a situation between these two poles that works well, and I expect that what works best for you is both a personal choice and situated. There's definitely value in capturing the cost of each change. In a framework like Scrum you can express the cost in story points, and the team can trade off the work they do in each iteration versus the total available effort. If you have a product manager you can get that person to quantify the expected benefit of a change or feature request. This is usually done in terms of protected revenue (how many customers would leave if you didn't do this) and attracted revenue (how many customers will arrive if you do do this). That can help with prioritisation, but can also just reflect the bias or personal preference of the product manager.

Improve this answer
2

Here some thoughts ...

There is plenty software in the market that helps you, http://www.fogcreek.com/ with Fogbugz , GeneXus USA with XPM http://www.genexususa.com/xpm , etc.

It's like an art to balance new feature requests with bug fixes and with your own ideas. You have to get food for the next winter, but you have to eat today too.

You have time, resources and scope, make your best out of it.

Henry Ford also once famously said, “If I’d listened to customers, I’d have given them a faster horse" ...

Personally: be dynamic, don't put rules like the ones you said... and be careful with other people's rules ... they may work well in their context, but not in yours.

Improve this answer
2

What we ended coming up with was we would now have bi-monthly sales/engineering meetings to discuss current projects and upcoming or future feature requests. The sales engineers will become project managers and at least they will be in tune with the latest product offerings. In the past it was just easy to pass it along to Engineering and forget about it. This will likely lessen the load a software engineer has to do and put the onus on sales and management to use our time wisely.

Improve this answer
1

The company I work for uses two main applications, a web based tool called JIRA to handle the project related aspects and our help desk system to handle the change request via it's rfc functionality

Improve this answer
1

The answers I see thus far are good. One thing that I will specifically spell out is that you are going to have to be good at saying "No" to some requests.

If you allow the customer to set the urgency, it will almost always be "High" (or greater).

You (either you yourself, or a team, depending on your setup) will need to evaluate these requests, and prioritize them based on your own criteria.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.