Obviously, we are working very hard to get our code working, get that project out of the door, writing golf, learning new technology, polish existing knowledge, prepare for better employability etc..

So much for technology. What monks think about the non technological factors that can make your projects successful? What can give better grasp and control over project environment, which is independent of technology?



Replies are listed 'Best First'.
Re: Non-Technical Factors
by rob_au (Abbot) on Jul 07, 2005 at 23:57 UTC
    The Standish Group performed a study (The Standish Group, "Unfinished Voyages" (1996), on factors which contribute to the success of an IT project. These factors were subsequently ranked with respect to relative importance:
    Success Criterion Relative Importance
    User Involvement 19
    Executive Management Support 16
    Clear Statement of Requirements 15
    Proper Planning 11
    Realistic Expectations 10
    Smaller Project Milestones 9
    Competent Staff 8
    Ownership 6
    Clear Visions and Objectives 3
    Hardworking, Focused Staff 3
    Total 100
    The results of this study go to suggest that project success is most likely to be achieved through involvement of project stakeholders, support of the project at an executive level and clear statements of requirements - Some pretty interesting stuff to remember when working on IT projects.

    Update - Information about the Unfinished Voyages study can be found at


    perl -le "print unpack'N', pack'B32', '00000000000000000000001000000000'"

      I find it difficult to believe that "Competent Staff" ranks so low. I also find it interesting (not necessarily good or bad) that this list seems to support what's currently en vogue as far as development methodologies go. That is to say, the above table looks an aweful lot like a checklist for agile methods.


      Feel the white light, the light within
      Be your own disciple, fan the sparks of will
      For all of us waiting, your kingdom will come

        I find it difficult to believe that "Competent Staff" ranks so low.

        Even with the very best people most projects will foul up without user involvement, management support, decent requirements, etc.

        That is to say, the above table looks an aweful lot like a checklist for agile methods

        More like a list of the things that agile methodologies try and address. For example the agile-folk approach to getting a "Clear Statement of Requirements" is rather different from that of the non-agile folk :-)

        It is worth reminding that this is a list of relative importance of the identified factors - Nothing on this list should be considered as unimportant in the success of an IT project, but rather the weighting is a reflection of relative importance within these factors alone. It should be noted too that none of these factors are methodology specific - Indeed some of these success factors have been identified by other contributors to this thread and are consistent across not only software development methodologies, but also distinct project management and risk management methodologies.


        perl -le "print unpack'N', pack'B32', '00000000000000000000001000000000'"

Re: Non-Technical Factors
by kvale (Monsignor) on Jul 07, 2005 at 17:27 UTC
    I think the single best thing you can do to get a better grasp of a project is to take a break and get some distance. Go running, grab a bike, or walk down a street you have never been before. Details that you are currently mired in will fade away, leaving you able to think about the overall project and the people dynamics within it. And the extra oxygen to the brain doesn't hurt either.


    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Non-Technical Factors
by coreolyn (Parson) on Jul 07, 2005 at 17:52 UTC
    Root access and uninterrupted time.
Re: Non-Technical Factors
by themage (Friar) on Jul 07, 2005 at 18:15 UTC
    I was thinking about non-technical factors that could improve my performance.

    First, I think that I need to start closing my office door, as I work home and now that my wife is free of school and almost all day seeing tv or doing other noises around home, I have an even harder time concentrating. This is non-technical.

    Second, I need to get some cooler installed here. The house is hot as hell, and with two computers (my workstation/laptop, and a server) working in here, my officeif even hotter. This is also non-technical.

    Thirst, I must visit perlmonks only once a day. Wait until my unreadden emails count at least 50 (a couple hours, most), read my Camelot Digest in the morning, and do go to every site listed at least once more a day, and other things like this. This is also non-technical, and even harder to solve than the previous two.

    This would improve greatly my performance, I think.
Re: Non-Technical Factors
by samizdat (Vicar) on Jul 07, 2005 at 19:49 UTC
    Keep bosses happy. Help bosses keep their bosses happy. This recursive chain is not always related to code output. :D
Re: Non-Technical Factors
by Tanktalus (Canon) on Jul 08, 2005 at 01:02 UTC

    This sounds like a leading question, in a forum where a significant portion of the participants just like having fun, and another significant portion don't like having boxes forced on them.

    Of course, the biggest nontechnical factor that makes projects successful is project management skills. (Whether these are worth the paper the diploma is printed on probably depends on where you're getting them.) These apply whether you're constructing a hi-rise, or writing software, or organising a Christmas party.

    But that's not nearly as interesting as some of the other answers you got because a majority of people here don't influence the management of their projects, so they want to answer from their own perspectives, not yours.

Re: Non-Technical Factors
by delegatrix (Scribe) on Jul 08, 2005 at 20:31 UTC
    Executive support is way at the top of the list. Along with that - having a good manager that will keep your projects in the minds of the executives and who can run interference is very important.

    Next, change management (and I don't mean CVS) is critical if your project brings about a change. Remember all change is bad an everyone fears change. I'm involved in a project to consolidate web development. Talk about a jolt to the system. Change management for me includes talking to the stakeholders constantly to make them a part of the process - to hear their concerns and account for them in the project plan.

    And then there is scope. Make sure everyone has a clear notion of the project's scope. Even if everyone hears the scope and all nod in agreement, there could be many different interpretations of what that scope was, so be as clear about the details and definitions as possible.

    To have better control over a project, a good communications plan helps. I also like to have a single point of contact with the client. "All requests shall flow from Joe Client and no one else". You can't have 12 people all sending you different information and making independent requests.
Re: Non-Technical Factors
by diotalevi (Canon) on Jul 07, 2005 at 23:33 UTC
    Executive level sponsors who know about the project and support it.
Re: Non-Technical Factors
by zentara (Archbishop) on Jul 08, 2005 at 10:55 UTC
    the non technological factors that can make your project successful?

    Use the first rule of capitalism: Create a demand for it, even if none exists. :-)

    I'm not really a human, but I play one on earth. flash japh

      Tolerance - is the permissible deviation from a project plan within which there is no need to request a decision from the next level of management.

      The standard tolerances that must be managed are time(schedule) and cost(budget). If you manage your project within the tolerances you have been assigned your project will be a success.

      To a large degree this just means identifying and managing the risks that impact on time and money. A clear head and some objectivity can certainly help for this as you may be a risk yourself :)

      The relative importance of project factors that rob_au lists might help find the factors that will most affect your schedule

Re: Non-Technical Factors
by Anonymous Monk on Jul 08, 2005 at 04:54 UTC
    I made 2+2=5 through tenaciousness and brutality.

    --signed BB