Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Starting a Large Project

by defyance (Curate)
on Feb 12, 2002 at 00:43 UTC ( [id://144745] : perlmeditation . print w/replies, xml ) Need Help??

A humble question for you more experienced Monks out there. I've never done a large project, not a program anyways, but I'm about to start one, and would love some advice.

What should I focus on first?

I'm struggling with this one, I have a big scope of where I need to start in my head, but I don't know if it is the right approach. I think once I get this part figured out, the rest should flow smoothly for me. I really want to get noticed with this, and really want people to look back and say that I handled it well.

Any suggestions?

-- Yes, I am a criminal. My crime is that of defyance.

Replies are listed 'Best First'.
Re: Starting a Large Project
by Ryszard (Priest) on Feb 12, 2002 at 02:08 UTC
    A few points off the top:
    1. Scope the project - on paper
    2. Meet with the stakeholders, get them to sign off on the scope
    3. Develop a plan, include design time, coding time, QA time, implementation time. Add extra fat to your timeline, becuase you'll need it.
    4. Once you have the conceptual design on paper, meet with the stakeholders - get them to sign it off.
    5. From the Concept design go on to write a detail design, (I use UML because its just so damn easy to learn and is very visual which suits me well)
    6. Submit your detail design to peers get them to read over your proposal and make comments.
    7. From the detail design talk with the stakeholders and make them understand how your project will run at a detail level. You dont have to go over the whole lot, just enuff to give them confidence in you. Get them to sign it off.
    8. Develop a prototype. At this point you can start coding. Put your basic business rules into code. With the meat of your apps, you can write stubs such as "Update the inventory here.\n"
    9. Show the prototype to the stakeholders, make sure they understand how things are being done.
    10. Develop meat. Add all the core functionality.
    11. Present developed app to stakeholders. They've signed this off, so they'll want to see the finished product before production. Compare your app to the signed off concept design/detail design.
    12. QA before a production implementation. You should *always* send something for QA. They'll test your app against a detail design, and do a bunch of other things like 'break testing', UI testing (if there is one) etc etc..
    13. Regular meetings. you need to show you are willing to communicate the status of the project. Even if the meeting is short, you should always communicate.

    There are of course lots of detail missing such as documenting your unit tests, usability testing, requirement gathering etc, however depending on the your definition of 'large' they may or may not be important.

    You may have noticed lots of 'sign off' comments. this is important for a few reasons:

    1. It demonstrates you are communicating with your stakeholders, (builds/ maintains confidence in you)
    2. They are getting exactly what they want, and you have proof. If they want something added toward the end of othe project, it should become a part of 'Phase II'
    3. CYA, CYA, CYA :-)

    In reality however, things never seem to go to plan. You may not be able to communicate with the stakeholders effectively, they may impose a 'vital' bit of functionality at the end, you may not have peers willing/available to comment on your design.

    If you follow some basic guidelines, communicate with the stakeholders, be honest about the status, you should be cool. Remember doco, its the most boring part of a project, but one of the most important parts. When you leave your job, someone else will need to know how/what you've done.


      Wow, such an awesome response, I'm printing all of this off for a refrence. Its amazing how willing you all are to open up ideas and suggestions to us not so "Experienced" persons. Thanks!!

      -- Yes, I am a criminal. My crime is that of defyance.
Re: Starting a Large Project
by dorko (Prior) on Feb 12, 2002 at 01:00 UTC

    Plan. Then plan some more.

    Don't just plan in your head. Write it down. Draw pictures. Develop flow charts. Think about the data structures you'll need. Work out rough dataflow diagrams. Think it through. (Given that it's just you working on this project alone, I wouldn't bother with a PERT/CPM analysis.)

    Set it aside for a day or two. Read it again. Plan some more.

    Time spent planning is never wasted.

    Good luck.



      Keep some paper and a pen handy, good call, for those late night revelations. Thanks guys, anyone else wanna throw some suggestions at me?

      -- Yes, I am a criminal. My crime is that of defyance.
Re: Starting a Large Project
by impossiblerobot (Deacon) on Feb 12, 2002 at 01:48 UTC
    For me, the most important step in any large project is putting together a good 'specifications' or 'requirements' document. If you can do this in enough detail, and have the client sign off on it, you can save yourself a lot of work.

    The specifications will still almost certainly change, but at least you and the client can have some measure of agreement that the requirements have changed, and it gives you some ammunition when changes in scope make a project take longer or cost more.

    Also, if you document every aspect of the design, including data structures, input/output, response time, etc., then writing the program is much easier, since all you're doing is translating the description into your language of choice (Perl, of course). Otherwise, you can end up writing a lot of code that doesn't do what the client thought it was going to do.

    Update: I forgot to mention that if you're ever coding and you find yourself trying to decide which way the client would like the program to work, your requirements document is not detailed enough, and you should probably stop coding immediately and go finish it. :-)

    Impossible Robot
      For me, the most important step in any large project is putting together a good 'specifications' or 'requirements' document. If you can do this in enough detail, and have the client sign off on it, you can save yourself a lot of work.
      I'd like to second, third, and fourth that. :)

      I've worked on several projects that skimped early on in the requirements gathering phase, and we suffered for it later. All I can say is, I'll never let that happen to me again.

      Designing a beautiful architecture only to find that it can't be made to meet the end-user's needs is no fun. Making up the requirements as you go along is fun for a few months, but then it starts to get old.

      As much as you can, it's good to know where you need to end up before you get started.


Re: Starting a Large Project
by belg4mit (Prior) on Feb 12, 2002 at 00:59 UTC
    One approach is to write a skeleton man page, this way you can define exactly what you wish to accomplish. To be honest though I usually simply start by implementing the core algorythym or interesting features of the project and extending and patching holes until I have a functional unit. I do come close to practicing what I preach though, usually before writing any code or after having written very little the idea will have been gnawing at me for at least a few days and I will of thought of features and possible implementations for various portions of the code. I reccommend keeping lots of paper on hand at all times.

    perl -pe "s/\b;([st])/'\1/mg"

      I pretty much do this but also write an outermost skeleton too.   There's usually some piece or pieces that you have to know how they'll work before you can really do anything.   Also, I get some data/input to feed to my empty shell of a program and even just to look at before I've done much of anything.   (But, then, after a while, you still have to write the darned thing.)
      update:   Oh, and get something visible running soon (for some definition of "works"), then you have the confidence/support to take the time to get it right.   Otherwise, no one can be sure anything's going to come of it.

      I take a similar approach, but even one step further.

      On large projects, I first write the meat of main man pages - consisting mostly of overall functionality, command line switches, etc.

      Then, assuming an OO project (in Perl or C++ -- and most large projects should be OO, imo), sketch out each object, and all of their public methods!
      For me this usually entails writing the document for the use of the class/module.

      I can't stress enough how critical this is on large projects, especially if you are, or will be working with others.

      On countless occations I've seen classes/objects gradually morph as the project progresses... eventually into hideous monstrosities. This is always a direct result of bad planning, or a lack thereof.

      ClassA, for instance, doesn't quite click with a part of ClassB.. so each add another method to fit together more cleanly. Then ClassC comes along and requires a bit different output from each of those, so A and B get new member functions that wrap existing ones, to return a bit different.... and so on and so on.

      If all components of the project are first mapped out, and their external interfaces designed in detail, all that is left is sticking the code in - and when these components are first mapped out, the coding usually is about 10% of the project.
Re: Starting a Large Project
by trs80 (Priest) on Feb 12, 2002 at 03:18 UTC
    From a design stand point there are so many different schools of thought on this and none of them is right for everyone. For me it seems to work best to work mostly in reverse, that is what do I want in the end vs. what do I need to build first. To do this I write down my understanding of the task at hand. I try to make this as detailed as possible. From there I try to determine the following

    • Recurring items
    • Related items
    • Areas that I know the least about programmatically
    • Areas that still don't make sense
    • Lifespan of the item I am creating
    • Target audience
    • What data I am manipulating and what container it should be stored in.
    • What modules on CPAN can cut my work time down

    I then take the recurring items and group them into modules and then do the same with the related items.
    The areas that I think are going to be difficult to program are mapped out in great detail on paper to determine possible approaches and weak points before I am looking at code and confusing code with process.

    If an area still doesn't make sense then the requirements are bad and the person who created them needs to be consulted. If you created the requirements then good luck :^)

    Lifespan takes on different forms. One is how long the code will be in use, the other is will the program run and end or will it operate in a server mode that effects caching and memory usage. Each of these will effect how you will approach your coding.

    Target audience is involved because this may determine how elaborate the user interface needs to be and/or where possible shortcuts can be taken.

    The container for your products data can really haunt you. Lifespan comes into this as well since again if it is only a temporary storage system that will be disposed of you don't have to as concerned. If the product and its data will have a long life you will want to take into account how the data will be interacted with in the future. Does it need to log things? How long do I think the storage method I am using will be available? Is it easy to interact with from other languages? There are many more questions and vary from project to project.

    Are parts of what I am doing on CPAN? This is more then important in my opinion, use CPAN code vs. reinventing the wheel. This can also be one of the tricky parts as well, since often times module names seem to fall under three categories.
    1. Right on, tells it like it is
    2. The correct technical term, but in reality most people know it by another name or might not know the correct technical term.
    3. What was that person thinking. The name doesn't fit the function at all and it is usually luck or word of mouth that brings you to this type.

    So I guess planning is what you should do first.

    Hopefully somewhere is that brain dump someone fines something useful. If someone thinks it is useful enough to refine and make a meditation out of let me know, but I am following my rule and thinking the lifespan isn't long enough for me to refine it any further. :^)
Re: Starting a Large Project
by MAXOMENOS (Scribe) on Feb 12, 2002 at 02:29 UTC
    I can't add substantially to the material posted here, so I'll add a nit instead.

    After you know what a piece of code should do, and before you implement that piece of code, you should write a unit test for that piece of code. This is just so you can be sure that your component works properly, before you go on to build bigger and badder things.

    The more crap your unit test does to your component, the better off you will be. Test basic functionality, test weird cases, do stress-tests, throw bad data at it, etc. Learn how your components behave, improve them, and get your component as good as you can possibly get it. It might not hurt to throw in a couple of performance tests, either.

    I've gotten bitten by not doing proper unit testing. On the other hand, I once managed to turn my reputation around from 'incompitent' to 'damn, he just saved the contract' by doing proper unit testing.

    Just two cents, and sorry I don't got more.


      I used to just scoff testing off till the end but now I'm a total test junky. It saves SO MUCH TIME.

      ADDED: Chromatic's article on is a great introduction.

Re: Starting a Large Project
by toma (Vicar) on Feb 12, 2002 at 07:58 UTC
    You have asked an interesting question and I would like to interpolate a bit. The question is not:
    1. What is the easiest way to do it?
    2. What is the best way to do it?
    3. What is the most efficient way to do it?
    4. How do I make sure I can get paid?
    5. How do I cover my ass?
    I read this question as "How do I look really good when this project is over?"

    You should be able to draw the 'big picture' of your approach on one page. This picture might be complex, but you should be able to point to it and explain what each part of the picture is supposed to do. This is the thing to focus on first.

    The best way to draw this big picture is to use a whiteboard and iterate versions of it until you think it is perfect. Be sure to put your name and the date on the picture.

    Now for the tricky part. You need to get the picture onto some paper. The best case is that you have a whiteboard with a printer attached to it. If you don't have that tricky bit of technology, transcribe the board by hand on to a sheet of paper in ink. When people see your architecture written in ink, they will be intimidated. This is good. You don't want some idiot rearranging your work for no good reason.

    Then code like hell and make as quick and dirty a prototype as you can. Use real test data provided by your customers as a demo. Show it to your customers and have them tell you what they *really* wanted. When they ask, 'can it do this or that?' don't worry about how much effort different approaches will take. Just say "Sure, it can do that! The important thing is that's what you really need." Think through the implications with the customer as best you can, throwing caution to the wind. Keep a list of every single request for change.

    These conversations with users will tax your ability to back off and see from the customer's point of view. Don't worry that minor changes may have major impact on your code. Don't try to defend your design decisions at this point, just try and see how the system could truly be improved.

    Next you have to decide if you can salvage your proto or if it is best to start over. Since it is your first big project, you'll probably need to start over. No big deal. Look at the big picture you drew. Is it still right? If it's wrong, don't fix it, file it under 'prototype' and redo the whole thing. You did it in ink anyway! Now, go through your list of changes and see if every single one of them is all fixed up in the new system. You might find that a few of the requests really don't make sense in the new system. Go back to your customers and see if these items can be worked out another way. Emphasize to the customers that you aren't looking for compromise, you're looking for the best solution possible. Not necessarily easy for you to implement, but at least possible for you to implement within your constraints.

    This time you code it carefully. Use the advice given in the other responses to your question, especially using revision control and building test code. Use revision control from the start. Continually improve your coding practices throughout the development of the prototype. In the second version, back off and simplify your coding style a bit, using only things that worked well in the prototype. Don't get grandiose and try to solve a larger problem or use new untested techniques in the second system, instead solve the problem in a simple yet comprehensive way. You'll notice that the code gets larger and more complex as you add all the necessary error checking and handling of special cases, so start simple to keep the code from becoming too big of a mess.

    Show it to the customer again. Find out if this system is better than the prototype. It might not be! You might want to iterate again, this time keeping true to your original vision. This isn't so much trouble; since you've coded the thing twice now, you're getting good at it!

    To summarize, my advice is to draw nice system diagrams by hand. Build a proto, get feedback, start over. Understand the system from top to bottom and be able to sketch how it works at every level. Work hard and keep the design of the whole system fresh in your mind.

    Imagine that your bosses' bosses' bosses' boss is coming to review your work one day. You have a wad of slideware about the system to show to the Big Cheese. The slides have been reviewed and sanitized for political correctness. But when you get to the meeting, the big boss says, "I've been looking at slides all day and I'm tired. Just draw me a picture of the system and explain to me how it works." You'll be able to think and draw on your feet while speaking clearly. That's looking good!

    It should work perfectly the first time! - toma
    please msg me if you think this is writing style is too hard to read. I'm working on it and I need feedback! Thanks, -toma

      Excellent post, good writing style, ++! I'd ++ twice if I could!
Re: Starting a Large Project
by dreadpiratepeter (Priest) on Feb 12, 2002 at 03:42 UTC
    Reading between the lines of your question, I'm gathering that you are going to be chief-cook and bottle-washer on the project. I find that is is just as important to be disciplined on a one-man project, but n-times more difficult. Documentation, clean code and rigorous testing against requirements are just as important on a one-man project as a 100 man project.Even if you are the customer of this project, follow the process. You'll thank yourself later.
    Leaving aside the excellent project lifecycle comments already posted, I would make a couple of suggestions on the design and coding part.
    First, there are 2 books that you should read before tackling a large project. They both by Microsoft Press (stop laughing! No, really I mean it!) Code Complete and Writing Solid Code, both are excellent studies of how to code effectively, and how to test effectively and how to debug effectively. Conclusions as to why Microsoft doesn't produce better software aside, these are indispensible resources.
    Second, if you are looking for a place to begin- think data and data structures. As James Brooks says, paraphrased from The Mythical Man-Month, (which I don't have in front of me) "Show me you code and you've shown me nothing, show me your data and you've shown me everything". (Actually, make that 3 indispensable books. Read Brooks as well, especially his "plan to build two, you will" essay). Anyway, think about you data. How it will be store, retrieved, manipulated, past around, verified and tested. Build tables, normalize, set boundry conditions, determine dependancies and relationships. Once you know everything about your data the code will write iself.
    Third, plan and built test cases from the very beginning. As you add features add test case to test them. It will be much more effective than going back later and trying shoehorn tests in. Look at the testing tools that come with perl, or search PM.
    Keep a todo list and a changelog. Each day update the changelog with bullet items of what you added or fixed. It will motivate you and give you a sense of accomplishment. Everytime you have an idea for a feature add it to the todo list and periodically scan it. (Neither of these are substitutes for a good MR systema nd a good source code control system).
    Without knowing more etails about the project I can't give more advice.
    Good Luck and Think Big,

    Entropy is not what is used to be.
Re: Starting a Large Project
by screamingeagle (Curate) on Feb 12, 2002 at 02:03 UTC
    you might want to break it down into several small discrete milestones , which you can try to complete one at a time, eventually linking those steps at the time of integration testing.
    as you debug and test each step, the next milestone in your project will be less susceptible to bugs and errors caused by the steps preceding it and should, on the whole, make it more manageable to manage the entire process
    I would also recommend saying a small prayer to the Gods of Perl every morning before you start to code... :-)

      I would also recommend saying a small prayer to the Gods of Perl every morning before you start to code...

      <horn action="toot" type="own">
      You mean like this one? ;-)

Re: Starting a Large Project
by dws (Chancellor) on Feb 12, 2002 at 03:59 UTC
    I have a big scope of where I need to start in my head, but I don't know if it is the right approach. I think once I get this part figured out, the rest should flow smoothly for me.

    If by "scope" you mean mental picture for how the system will fall together, I suggest you take one step back, and focus first on how the system will be used, and then get real users to validate your usage model. Otherwise, you risk doing a great job of building the wrong thing.

    One quick way to develop a usage model is to use storyboarding, where you use pictures (e.g., prototyped screens shots) to walk users through a typical use of the system. This gives users something tangible to give feedback on.

    If you want to get more formal, you can capture usage scenarios in "Use Cases". (Most books on the UML or the Rational Unified Process will tell you more than you need to know about Use Cases). I've used Use Cases on big projects, and have seen a good payoff.

    Then, once both you and your target users are satisfied that you're building the right thing, use some of the excellent advice in the posts above.

Re: Starting a Large Project
by Phaysis (Pilgrim) on Feb 12, 2002 at 03:33 UTC
    I am going through something quite similar. I have a personal project, and it is, to me, rather large. Yes, folks, it's Yet Another Perl Database-Driven Web Templater.

    I've been planning, dreaming, and mucking-about with this thing for over a year now and it's now time to do something about it. I've divided my code into modules, chunks, and units based on general, generic functionality (note: keep your options open: use generic functions; this will give you building-blocks for more complex functionality later). I've finally gotten the dataflow, object linkage, and program flow straightened out and down on paper and whiteboard, posted for quick reference, and this is a Good Thing. It helps immensely.

    Now that things are planned out and chunked into smaller bits (one module for getting the request environment, one module for templating, one module for logging, etc.), I can begin working on each part in order of most-independent to most-integrated. For each module I build, I'm using test scripts and doing unit testing to make sure the functionality, logic, and conformance to normal and strange cases is as I need (a working directory filled with test scripts is nothing out of the ordinary). So, after about a week of making steady headway on this project, I'm seeing the light at the middle of the tunnel, with overall testing, debugging and profiling on the other side. The Big Green Light at the end of the tunnel is always in my mind, but I must keep it in perspective and go towards that goal. Baby steps, man.

    Most of the suggestions listed here are top-notch suggestions, and worthy of getting into hard copy. Personally, I'm glad that you asked, defyance. I too needed some validation to the copious steps I was taking on my own project. I suppose a nice side-benefit to working on your own Large Personal Project is that you sign yourself off. Y'know?

    Best of luck, one and all.

    (Ph) Phaysis
    If idle hands are the tools of the devil, are idol tools the hands of god?

Re: Starting a Large Project
by tune (Curate) on Feb 12, 2002 at 02:39 UTC
    Yes it is a really nice detailed list of steps of the process.
    What is bothering me (The Programmer) that usually I just want to do steps 8-13, the others should be taken care by someone called Consultant, or Organizer, I don't know the exact description of the position.
    However if you are in a small organization, you are expected to do the whole process by yourself.


Re: Starting a Large Project
by rbc (Curate) on Feb 12, 2002 at 04:50 UTC

    Did I mention documentation?

    I good functional spec and
    a good detailed design document
    are well worth the effort.
Re: Starting a Large Project
by ignatz (Vicar) on Feb 12, 2002 at 11:04 UTC
    The thing that I focus on first is the design of the database. This tighly integrates with Class design as one flows from the other. It's much easier to fix weak code than it is to fix weak data.
Re: Starting a Large Project
by George_Sherston (Vicar) on Feb 12, 2002 at 17:11 UTC
    Here's another twist on the good advice above. Right at the start of all the big projects I've done (I confess - this is not very many) I write a description of what it's going to do in language my mother could understand. Something like

    When you switch it on you see... Then, you can press a button called "Foo", and if you do that you'll see... On this page you have some information about Blah, and several options: a link to "Bar", a button marked "Baz"...

    After I've done that, I usually find that I've exposed any stupid assumptions I was hiding under technical generalisations, and I have a pretty good idea of how it breaks down into subroutines (and where code re-use is likely to happen). And as a bonus I have the basis of a pretty informative set of comments to imbed into the programme.

    George Sherston

      There's nothing I could add regarding the technical aspects of your project, beyond the excellent advice above.

      On the other hand, there may be a few points to draw out concerning career advancement.

      Wheterh you are in an organization or consulting, it can be very advatageous if the people for whom you're designing feel confident and comfortable, not just when all ends well, but throughout the whole process. You want your superiors/clients to say "He had it under control the whole time, we were never exposed to risks."

      That means using the user-input / planning / sign-off / validation steps mentioned in other posts as, in fact, public banners advertising your project management competence. Get user input by distributing written invitations, with copies to management. Distribute your plan, with copies to management. Confirm the sign-off in writing, with copies to management. Etc. You might even start out by publishing your intended steps so people know what to expect.

      /me is taking notes...

      Seriously, I'm printing this stuff off.

      -- Yes, I am a criminal. My crime is that of defyance.
        I read this question as "How do I look really good when this project is over?"

        See, I know that's probably the way it sounded, but to explain myself a little, that is not my intention at all. My ultimate goal with this project is to make someone's life just a little bit easier anyway I can. Now I will mention that yes, I would like to get some recognition for this, and the money is a plus, that has been made known. I don't think I stressed the initial reason, however, for accepting this project. Even before I first entered the world of Technical Support, and Programming, My ultimate goal in life was to make things easier for someone, somewhere. Not many people have such a strange goal, but I do, and that's what led me to programming. I'm ecstatic that I'm finally getting the chance to do it! That's why I wanted as much advice about this as possible, I don't want to screw it up, and not accomplish a lifelong goal!

        I'm sure this sounds like a line of bull to most of you, but this is truly from the heart!

        -- Yes, I am a criminal. My crime is that of defyance.
Re: Starting a Large Project
by weini (Friar) on Feb 12, 2002 at 06:07 UTC
    How could I dare posting here, being a beginner myself?

    I learned a lot reading all these answers and there is only one thing I can throw in the discussion:
    You can manage all this gathering of ideas and buildung of structures by the instrument of Literate Programming.

    It helps me even for small scripts and I guess it will do a great job on large projects ... and it's easy to learn - I know what I say ;^)

    Just my two cent ...


Re: Starting a Large Project
by zakzebrowski (Curate) on Feb 12, 2002 at 13:10 UTC
    FYI tools: You might want to look at microsoft project for project management issues (design charts etc)... (Not really a microsoft supporter but a tool is a tool). There is also a couple of cool flow chart tools etc. on linux for free and other stuff as well. There is a bunch of "request / bug tracking" tools available from source forge... (though I haven't had enough time to actually get some of those tools working...) Also a financing tool (money, quicken etc) might come in handy. I would also set up a developer an announce mail list that you can send email to to ensure people are on the same page... I would also try to ensure that people could contact you whenever and you'll be able to respond to them within a 1/2 day... ... etc ... just woke up, not enough coffee yet... back to sleep...

Re: Starting a Large Project
by jlongino (Parson) on Feb 12, 2002 at 22:53 UTC
    I noticed that there were very few mentions and little elaboration on output/reports. Is this not a consideration with this project? Almost all of the larger projects I've worked on have core requirements in this area (whether in written or electronic form).

    In the few instances where I've made design mistakes, they usually stemmed from the fact that I failed to examine the required output/reports closely enough or made wrong assumptions (though usually valid) based on experience. Recently I was given an example (publication) to work from and found out later in development that they had changed their example substantially without telling me. Thus the need for constant design/programmer/customer feedback throughout the life cycle of the project.


Re: Starting a Large Project
by Anonymous Monk on Feb 12, 2002 at 22:02 UTC
    How you go about attempting a large project depends, in part, on what the expectations of your client are. Steve McConnell's book "Rapid Development" touches on various project management methodologies, and explains how one methodology might be better than another given your particular situation. The book is a good read with many humorous, anecdotal examples how to NOT run a project (and, of course, how TO run the same project).

    Project management is alot like programming Perl. TIMTOWTDI.

Re: Starting a Large Project
by tjh (Curate) on Feb 13, 2002 at 02:09 UTC
    There is so much good advice already mentioned...

    I can only add my 2 credits worth:

    1. Where do I want to end up?

    • What does the UI do? In as much detail as I can imagine.
    • What management interfaces are needed and their functionality? Including reporting interfaces.
    • What is the overall description of functionality (in Reader's Digest English)
    2. I believe that this works in gradients of completeness.
    • Get some initial results. Core functionality. This is good for my morale, as well as that of the other stakeholders.
    • Expand the core functionality towards 'releasable functionality', which may not include all the planned functionality.

    This will be a debatable point, but since I tend to think that a good project/product is almost never truly "done", then targeting a release of useful functionality works for many (but certainly not all) projects. We're able to show a product, maybe sell it; involve users, support staff, and others in continuing development as the additional functionality continues to come online, etc.


    Projects tend to change, sometimes radically, from their initial scope. Nothing new in that thought.

    So, I began planning in the unplanned request, the midnight revelation, or the damn business plan changes. My own projects experience the same things. I'll start out in one direction, usually get to the releasable functionality step, only to find new features, functionalities, or even different uses from what I started out to get.

    Forever, those seemingly inevitable changes seemed like Evil. Eventually, when I began working with these flexibilities in the initial planning stages, and throughout the actual coding/testing/release stages, things smoothed out remarkably.

    However, it is sometimes a tense moment to explain 'releasable functionality' to those that think they know or designed a foolproof plan and scope. And none of this precludes definable milestones, deliverables schedules, signing off on scope, changes, turnovers, etc. But, realizing that "it's going to change" and working to define and quickly arrive at useful milestoned deliverables has saved me/us from many antacid-filled nights.

    Sometimes, releasable functionality represents a business plan change as well as a coding release schedule. So, if it's not really my place to make such a suggestion, or if the project has iron-clad scope (rare?), then I forget about that thinking (which hurts, since I tend to think it's a valuable approach, even if the first releasable isn't actually rolled out).

    (My favorite post-planning question has turned out to be: Ok, so we've done all this planning, accounted for every possible problem, completed and rolled out the product, and it still fails. What are the top 3 reasons why it will have failed?)


      I wonder if someone would like to devote some time to writing a manual about this subject! It could be done from notes in this node!

      -- Yes, I am a criminal. My crime is that of defyance.