When we start to work on big projects in production settings, it becomes clear that there is a lot more to software development than just writing (Perl...) code.   Projects that are being spearheaded by the best Perl coders out there sometimes founder.   To a corporate employee, that’s an awkward situation.   To a contractor or a freelancer, that’s unemployment.   So, even to a “lone wolf” in a “one-man band,” the total process is important.   Yet, especially when the pressure to “get ’er done” is already intense, it can get short shrift.

So, I would like to Meditate on the kinds of “process improvement things” that we can actually do, within the limited (human) resources available and in addition to all the coding we have to do, in order to make our overall situation better.   I invite other Monks to please chime in.

Manage the project from the start, and do it in front of (and with the full participation of) the Stakeholders:
That means Microsoft Project or OpenOffice.   It means having an issue-tracking system and source-code control from the very first day ... even if “it’s only you.”   It means capturing what is going on from day to day, instead of relying on your scribble-notes and memory.   It means planning the work and then working the plan.   Religiously.   The folks outside of the implementation team need to be involved frequently and early.   Have regular meetings with an agenda.   Keep a “running log” of every day’s work by every person.

Insist on regular working hours, not “heroism”:
“Steady, steady wins the race.”

Don’t attach a stigma to the “defects list”: You need to capture every issue, open or closed, and up-to-date notes about everything that is being talked about, worked on, or tested.   That means that you must not attach a stigma to doing so.   No charts of “issue status.”   No graphs showing the number of items closed this week.   People will tell you what they think you want to know.   In any creative endeavor, the number of “sticky-notes on the refrigerator door” might blossom into the hundreds or even thousands.   You want there to be lots and lots of those notes, so that nothing gets overlooked or goes unnoticed.   It is pointless, and counter-productive, to count them.

To be continued...   Fellow Monks, please take it from here.   What do you think?   What’s your experiences?   What else would you add?

  • Comment on Idle thoughts on software project-management

Replies are listed 'Best First'.
Re: Idle thoughts on software project-management
by bellaire (Hermit) on Feb 19, 2011 at 04:19 UTC

    With emphasis on the small team (4 of us here) serving the semi-technical group (internal systems for a university IT division)...

    Listen carefully...
    Customers ask for lots of things, knowing they won't all get done. They don't really understand the effort differential involved... but they do know what's going to save them effort. Your job is to extract that information from them. I recently did a job in a day that a customer told me would save him hundreds of hours of effort per year. He didn't understand that the ROI on what he wanted was so great because he didn't know that it was so easy to implement. Ask questions, figure out where the cost savings are, and target those aggressively.

    Be able to say "No..."
    Especially when you're salaried and you dont make money per-job, it's easy to just say "Yes" to anything and everything anyone asks for... But that doesn't get you much. You'll start breaking promises and you won't make a good impression. Instead, try to talk to them in their own language about priorities. Explain that they can have X or Y in 4 months, but not both. Usually they understand that they can't have it all and will be able to help you to say "Yes" to the right projects.

    Be prepared to pivot...
    The XY problem can easily manifest itself in customer-programmer relations. When the above rules fail, you can find yourself implementing a system that just misses what the customer actually wants. By keeping in contact with stakeholders early and often, you can detect when this happens and change your approach accordingly, with a minimum of waste. Some waste may be inevitable... chances are sometimes you and your customers don't speak the same language, and they don't understand that you're solving the wrong problem until you can show them a prototype. So... do the prototype. Do the minimal work that will illustrate your solution, show it off, and be prepared to abandon it if you're off the mark. And do it as early as possible.

[reply]

      With regard to the above, one thing that I am seeing more and more is ... the fundamental value of classical project management practices.   People who are not experts in a particular field of expertise (be it computer-programming or plumbing) might know what they want to achieve but not how to say it; nor how to judge it.   They have money to spend but don’t know the prudent way to spend it.   They are always accountable to someone else (ad infinitum, right on up the line...) for the money and for the trust that they have vested in you and in your project plan.   We all have a natural aversion to “paperwork,” until we witness for ourselves the extreme value of it.   And, I think that we all like to think that our particular endeavors play by a different set of rules.   (We are constantly inventing a new set of industry-specific buzzwords and silver bullets.)   More often than not, though the practices that have been applied for a very long time in many other, seemingly unrelated disciplines, do apply very well to what we are doing for our daily bread.   It has been said, “if you want to find something new, look to the old.”   And I am finding that to be truth.

      Write technical documentation as well as some for the managment and customer
      This can't be empasized enough: You will have to deal with (at least) three different groups:

      • The technical group needs specific instructions. What is required, how is the software required to do it, the exact message-by-message, byte-by-byte specification of any required communication with other systems
      • Your own managment needs an overview of how long it will take, how much it will cost in man-hours, any required external resource (servers, services, ...). Managers do not want to wade through technical specs. They do want to know however if they will be able to afford a new car or get sued by $other_company.
      • Your (internal or external) customer wants one document from you: The ability to RTFM. This manual should have nice pictures, easy-to-understand "if you want to x enter y in there and click z" paragraphs. Please avoid technical explanations like "The driver hooks into the kernel by patching the system call table"...
      If possible, write as much of the documentation as possible before starting to code. Let the customer and managment review it. While your software may still fall short of the customers expectations in the end, this will minimize the risk.

[reply]
Re: Idle thoughts on software project-management
by locked_user sundialsvc4 (Abbot) on Feb 18, 2011 at 14:38 UTC

    Oh, fudge.   Perlmonks logged me out.   (As should come as no surprise to any of you...) I’m the “Anonymous Monk.”

    (Full disclosure:   I hope that no one objects to my having just “approved” it.   I didn’t contrive to do that, or any such.)

      nevermind,
      it was a pleasure to read the post.

      I agree on all items,
      and also I have some ideas, but I do not have organized them properly yet.
      Hmm, maybe I need to use proper mind mapping software (freemind? freeplane? other)

      What about UML usage? Or is it too Java-minded?

      What do you people this about this?

[reply]
      stats are pointless?
[reply]

Back to Meditations