http://qs321.pair.com?node_id=278129

Hello monks, How do you plan your programming projects? I mean at work or big open source projects. What are the procedures and files you fill out before you get start coding. How do you get your clients involved so they know whats going on during the projects. I ask this because our bosses want us to do more project management, but we have no idea how to start. We are a really small shop. One full time employee (me), two student programmers and one graphics design student. I'm looking for a method that works but doesn't bury us in paper work so we don't get anything done. Thanks for you insights. rlb3

Replies are listed 'Best First'.
Re: Project Management
by dws (Chancellor) on Jul 26, 2003 at 21:25 UTC
    I ask this because our bosses want us to do more project management, but we have no idea how to start.

    Step zero: Make sure you understand exactly what your boss means by "more project management".

    There are hundreds of project management books, though most are for bigger projects than yours. There are hundreds of books on methodologies. The two topics overlap. A lot depends on how formal your boss wants to pay you to be. You can accomplish a lot with a whiteboard and post-it notes.

    I plan projects by first understanding what's important to the customer. This typically involves capturing information about the system as Stories or Use Cases, then sitting with the customer to prioritize them. From there, some sort of work plan gets generated. Developers are asked to look at the stories, sketch out an implementation and provide an estimate. These get lined up to develop an iteration plan, with some number of iterations resulting in a release.

    Each iteration is also a replanning point. Priorities change, new requests come in, developers learn more about how difficult some things are (or aren't). The team establishes a true "velocity" (as opposed to the wild initial fantasy about how long it'll take to do things). I lay out a new iteration plan after each iteration. Mangement might throw fits about this at first, but they often get used to it (or they might fire you).

    For small projects, I'll do this on a whiteboard. Developers can then cross off their task cards when they're done, or update estimates. Management can then wander by and look at the board to get a handle on progress.

    This approach leads right into eXtreme Programming (XP), should you decide to go that direction.

Re: Project Management
by cchampion (Curate) on Jul 26, 2003 at 21:21 UTC
Re: Project Management
by Beatnik (Parson) on Jul 26, 2003 at 21:12 UTC
    Get one of those huge whiteboards and some markers. Draw out the program schemes on it, which parts interact with which parts. In Uni we got all this UML and ERD stuff and it seemed rather silly but I found myself doing those exact same things when working on something. The reason why I use a whiteboard (and not some fancy, expensive program) is simply because I'm sure I'm (changing my mind|coming to my senses) at some point. If you're all done, you can still use one of those applications to draw it.

    Update: David Caughell /msg'ed me about using a digital camera to save the flowchart... I already did that, as can be seen here :)

    Greetz
    Beatnik
    ... I'm belgian but I don't play one on TV.


      Creepiness -- I have a whiteboard roughly 20 inches by 10 that I actually took to carrying around with me, because it was so much more comfortable to me than pen and paper at one point. I also took to carrying a digital camera around because I lamented that it was so temporary, and if I needed more room I had to erase stuff.

      I don't know why -- I'm just more comfortable on a whiteboard. Once I can get another digital camera to replace the other one and go back to classes (probably this fall), I'll probably do it again. It served me rather well...

      -----------------------
      You are what you think.

        You can always use a PDA to scribble down quick flowcharts (which has a smaller screen anyway).. You can also use one of those webtablets :p

        Greetz
        Beatnik
        ... I'm belgian but I don't play one on TV.
Re: Project Management
by BrowserUk (Patriarch) on Jul 26, 2003 at 21:25 UTC

    Of the development methodologies I used (or more often than , been forced to use:), and there have been many some less elaborate and some more so, the only one I could recommend is XP.

    Don't let the name that sounds like a late '90s "No fear" recreational pastime put you off, its the only one I've used where the project doesn't become secondary to the methodology. That is to say, the practices involved rapidly become second nature and something you don't want to bypass, because the benefits are rapidly apparent to (almost) everyone that uses it. It's the easiest to learn, most intuative to maintain, and it works.

    Unlike most of the others where the project management is percieved as a chore that only gets done when management nags you to do it, and for which any excuse is a reason to avoid, delay or abandon it. Or, as with things like UML (Rational Rose etc.), becomes a whole skill-set to be learned and an art in itself. You end up needing a project management and design team to manage the project management project:(


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Re: Project Management
by chunlou (Curate) on Jul 27, 2003 at 04:24 UTC

    We can think of project management embedded within the development process embedded within the business process.

    Business Process
    Marketing research, product idea development & positioning, sales pitch, etc. Development Process Customer support, sales pitch, etc. 
    Planning, coordination, bargaining, etc. Project Management Documentation, post mortem, etc. 
    Req. Elicit. & Analysis Design Coding Testing

    We will only elaborate Project Management a bit more. Notice that the table above doesn't signify the processes are a linear and waterfall one. In fact, project management is usually an iterative process. We could illustrate the iterative nature by journalizing the percentage of completeness of each project management phase as below.

    iteration Req. Design Coding Testing
    1 80%      
    2 83% 90%    
    3 84% 92% 50%  
    4 86% 94% 70% 10%
    5 88% 97% 90% 15%
    6 89% 98% 99% 50%
    7 90% 99% 99% 99%

    Notice, in practice, we never ever catch 100% of the bugs during testing, we might postpone the implementation and coding of certain things for whatever reasons, we might overlook something during design, and rarely do we have complete requirements for any project as requirements are constantly evolving things. Hence, no 100% anywhere.

    A goal of project management is to define the "acceptable " amount of information or artifacts we should gather at each step before we should and could move on to the next step, and who's responsible for what.

     

    Developmental Phase

    Role1. Req Elicit. & Analysis:
    "What to Do"
    Design:
    "How to Do"
    Coding:
    "Do"
    Testing:
    "Did Right?"
    Mgr/Client lead     verify
    Proj Mgr/Sys Analyst lead lead buffer
    disturbance
    coordinate
    Artist/Programmer (as needed) lead lead fix
    QA (as needed) lead   lead
    Artifacts: flowcharts,
    screenshots,
    use cases...
    DB schema,
    class diagram,
    site map,
    (prelim) test script2....
    (you know
    what...)
    results to the
    test matrix...

    1.Note that a single person could take multiple roles.
    2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.

    The table above adopted from Re: Re: XSL/XML/Perl as a development process. What "artifacts" you want to use are entirely up to you.

    In practice, I found a good execution of a methodology itself is more important and challenging. Challenging because a good execution requires good cooperation and discipline and the willingness to learn. But people tend to like to do things their own way.

    So, whatever project management methodology you use, make sure you secure the buy-in from your team members and your management, and the people have enough skills and knowledge to adopt the methodology, or else you're doomed, just like many other people before you.


    _________________________
    Footnote: No one likes paper work for paper work's sake. But do keep some form of written thing (electronic, paper, clay, or whatever) to document what you're asked to do and by whom. It's of practical and legal importance.

    Once two account managers looked at our developing product in process, they fumed when they noticed some "unanticipated" changes. Asked me why. I told them they told us to make the changes. They said they never did. I emailed them the email that indicated such a request was made by them. They never replied me back.

    That's why management buy-in is important to your project management.

    As for client involvement, showing them screenshots during requirement and design phases and asking them to play with a semi-working product during coding phase would be a good start.

    But also be aware that not all clients want to be involved. Some of them are like a plain-looking woman walking into a beauty salon saying, "Make me beautiful!" and leaving you no clues as to what she really wants.

    In fact, in a way, requirement elicitation is the most difficult job in project management. It requires the skill of a clinical psychologist or a psychic.

      In fact, in a way, requirement elicitation is the most difficult job in project management. It requires the skill of a clinical psychologist ...

      When you think about it, most people's internal (that is, imaginary) ideas of reality appear more real to them than reality itself, and the only corrective is pain -- like Ben Franklin said, "Experience is a harsh schoolmistress, but she's the only one fools will learn from."

      What's helped me most in that regard is a book from another discipline entirely than programming, The Structure of Magic Volume 1: A Book About Language and Therapy by Richard Bandler and John Grinder. It breaks down the actual skill of eliciting communications of fact that (competent) clinical psychologists use.

      It's also great for putting PHBs in their place, as in "What specifically do you mean, sir, by object oriented", and watching them proceed to flounder ... heh.



        Yeah, but Structure Of Magic II is more interesting...! I shows you how to ask interesting questions -- II shows ways to give interesting answers.

        -----------------------
        You are what you think.

      I'd like to thank everyone for there responses and their time.
      I am overwhelmed that the volume and detail of the replies.
      This is what make perlmonks one of my favorite sites.

      Thank you,
      rlb3
Re: Project Management
by adrianh (Chancellor) on Jul 26, 2003 at 21:31 UTC
Re: Project Management
by mjeaton (Hermit) on Jul 26, 2003 at 23:02 UTC
    As someone else mentioned, you should get clarification from your boss as to what he means by "more project management".

    What are the procedures and files you fill out before you get start coding.

    As I'm sure you already know, the most important "procedure" or step is to fully understand what it is you're doing. Don't get bullied into jumping right into coding (whether by a boss, client or yourself). Think through what you need to do and how you're going to do it. Create any documentation that you think you'll need to make the project go smoothly. If that's UML diagrams, flow charts, pseudo code than just make sure you do them.

    Of course a lot of clients will demand certain documents which you'll need to provide as well.

    How do you get your clients involved so they know whats going on during the projects.

    Well, you can approach this in a couple of different ways. The first would be monthly / weekly / daily phone calls to let them know how things are going. Always be as honest as possible with them. Remember, it's their money and they have a right to know where that money is going.

    The second approach would be to create some type of status web site where they can view updated project plans, status documents, design documents, etc. While you could try to make this your sole method of getting them "involved", I'd actually combine both of the approaches I listed.

    Since you're a really small shop, I'd suggested setting up a website that can easily allow the customer to view documents you've created (RDD, design docs, project plans, etc). We currently do this using a specific document naming convention and having a script parse the files in a certain directory to create the "Customer Status" site.

    Another option which I've used in the past is to get the client onsite for a few days (or weeks if necessary). Talk to them, get to know their business...

    mike