Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Projects HOW-TO

By tayknight in Technology
Wed Apr 18, 2001 at 08:36:23 AM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

I'm sure some of you out there work for companies or for yourself where you have to make pretty detailed plans for projects. I've been tasked by my boss to come up with a standard set of steps to follow when we start a big project. Hopefully some of you can help.


Right now we have a eight stage process (Planning, Requirements Definition, Detailed Design, Iterative Development, Testing, Documentation, Deployment, Completion). What we don't have is a good framework for how to do each of the steps in the process.

What I don't want is for all of the K5 community to do my homework for me. I do want to find out what works well for you. What steps do you take when starting a project that will involve multiple people and departments? What kind of questions are best to ask the client in the beginning? How do you integrate what graphic design does with what I do (programming) with what the set-up team does?

Obviously I could ask tons of questions, but I'd like to get your feelings for project planning, development, and deployment. Does this process have a name? Thanks.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What is the most important part of a project cycle?
o Site Survey 0%
o Planning 53%
o Development 17%
o Testing 12%
o Deployment 2%
o Follow-Up 14%

Votes: 41
Results | Other Polls

Related Links
o Also by tayknight


Display: Sort:
Projects HOW-TO | 26 comments (24 topical, 2 editorial, 0 hidden)
In my experience... (3.00 / 1) (#1)
by Sairon on Tue Apr 17, 2001 at 11:35:01 AM EST

it really comes down to the company/group. I had to build a system in a company that had no concept of handling projects in a consistant and documented manner. I had to come up with my own way and evangelize and forcefully implement. Now I'm working on my own company and we're working on implementing ISO 9001-3, which follows along with many of my orignal ideas. I recommend checking it out. Sort of a framework for porject management in-a-box.

JPM

NB (3.00 / 1) (#2)
by greyrat on Tue Apr 17, 2001 at 11:36:24 AM EST

Testing and documentation are not processes that occur after iterative development -- or requirements gathering and detailed design, for that matter. They occur in parallel with the same kind of staffing and requirements.

And yes, it has thousands (well dozens) of names. Do a Google search on "Software Design Process" and start reading.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

Book Recommendation (4.00 / 1) (#3)
by trust_no_one on Tue Apr 17, 2001 at 11:45:54 AM EST

A good place to start might be to read through Steve McConnell's Software Project Survival Guide. It gives a high level overview of each of the steps in the software development process. It will help you understand what is involved in each step of the process, and what work products need to be completed before you can move on to the next step.

To get a feel for his style and thinking, you might want to check out his web site. A lot of useful stuff to get you started.


I used to be disgusted, now I try to be amused

The order needs work, but... (4.66 / 3) (#5)
by Vulch on Tue Apr 17, 2001 at 12:08:28 PM EST

You seem to have the steps covered, but I'd argue about the order.

  • Requirements should always come first. What are you trying to do, what must the product do, what would it be nice if it did. If the idea has come from a sales droid, make them sit down and write a short requirements spec to give you a base line.
  • Planning and outline design. Roughly how much work is there, how many people would you like. How many have you actually got, and what are their specialities.
  • Detailed design and documentation of every interface between different work units. Sort out how everyones work will talk and listen before worrying about the insides. Irritating as review meetings can be, every interface should be reviewed by the two (or more if that is unavoidable) people involved, plus a referee (or "Project Manager" as they are sometimes known) and written down once they are agreed.
  • Design, code, document and test the internals. And have someone do a weekly build to make sure things will actually work together as agreed.
  • System test by someone other than the developers. The developers know too much about the code they've just produced and will avoid doing certain things without being aware of it. Get someone independent to do some serious testing. This will also show if your documentation is sane.

Keep everything in a CVS repository, including the documentation, and tag every single build and release. Hurt people if they check non-working code back to the main branch.

Make sure you've got one project manager, and that no-one bypasses them and goes direct to the development team(s) with suggestions or questions. There's nothing worse than a sales and marketing type coming along with a "X said this would be an easy change, so..."

Get the whole team out of the office somewhere once a fortnight without PHBs, admin or customers.

Finally (Well, maybe finally) make sure the project manager knows what is going on and is chatting to people. Relying on weekly reports for progress won't keep things on track.

Definitely finally. Be flexible. The S&M drone might actually have a feature worth incorporating. An API might be made to work better at the expense of a few days work and a rewrite of that bit of a spec. But don't get pressured into shuffling things because there is a presentation tomorrow and "wouldn't it be nice if we can show them this bit".

Anthony

Some thoughts (4.00 / 1) (#6)
by RangerBob on Tue Apr 17, 2001 at 12:11:54 PM EST

First off, project management is actually a well studied field. You can even pick up a degree in it these days. But, it's a big enough field that you need an understanding of it first before you start trying to make frameworks. Otherwise, you could end up messing yourself up pretty badly. What works well for one group might not work well for you, that's why it helps to have a good background in the concepts first.

One of the most well known people in this field is Kerzner. I think you can buy videos of some of his lectures, but you'd have to dig around to find where because I honestly don't know. One of his texts, "Project Management - A Systems Approach to Planning, Scheduling, and Controlling" is pretty lengthy, but it will cover just about everything you'd need to know.

If you haven't done it already, I'd highly recommend taking a class in this. I took one when I started managing projects and it's been extremely useful. We did focus on the Kerzner material, but it was some pretty good stuff.

You should also checkout www.pmi.org. This is the Project Management Institute and they have a lot of good information online about project management. You can also download the "Guide to the Project Managment Body of Knowledge" here. I think you can download the 1996 version in its complete form but the 2000 version only has a few of the chapters included.

Methodologies (4.00 / 2) (#7)
by zephiros on Tue Apr 17, 2001 at 12:21:16 PM EST

Well, first off, there is absolutely no replacement for project management experience and expertise. Nothing you get off the shelf can be used without a significant amount of customization and refactoring for the changing needs of the project. Having someone in the driver's seat who knows what level of process to apply to a given task is going to define, to a large degree, the success of any methodology you decide on.

For some shops, XP (Extreme Programming) might be a good option, because it forces good practice. If you don't have the time, budget, or expertise to apply a "real" methodology, XP is probably a good fit. IMO, McConnell's methodology is a better starting place for the serious PM. It introduces process, but explains why you're using it. It never attempts to suggest you "just do it." I think this is pretty key to getting PMs to the point where they can make decisions on their own, without falling back on "the holy methodology" every time they're faced with a decision.

Right now, my company is using RUP (Rational Unified Process). I'm pretty happy with it, as it gives the PM a powerful process (and a rich set of supporting documents) to work with, without expressly telling you how to run your project.
 
Kuro5hin is full of mostly freaks and hostile lunatics - KTB

PSP/TSP (4.00 / 1) (#8)
by wiredog on Tue Apr 17, 2001 at 12:26:59 PM EST

Check out the Personal Software Process at Carnegie Mellon's Software Engineering Institute.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage

For the love of god, don't (4.00 / 1) (#10)
by Luke Francl on Tue Apr 17, 2001 at 01:26:23 PM EST

For the love of god, do NOT, I repeat DO NOT, check out the PSP.

The PSP was inflicted upon me in my software engineering class last year. It is an absolute NIGHTMARE. You have to fill out a stack of paperwork for each step of the project, do elaborate statistical calculations, and all kinds of worthless crap.

Extreme programming strikes me as infinitely more palatable and useful.

[ Parent ]
Oh for God's sake!! (4.66 / 3) (#16)
by jabber on Tue Apr 17, 2001 at 04:23:02 PM EST

You didn't like learning about it so it's bad?

Look, filling out tons of paperwork, in some cases, is the only way to document WHY you shouldn't get fired when your project fails.

Any real development process is overkill when all you code is little toy projects for bored Professors. When you have several dozen developers, each of whom makes roughly $1/LoC in a 6 month project, all that paperwork suddenly gains a lot of value.

Read this!

Your argument is like saying : since I didn't enjoy reading The Taming of the Shrew (as taught by Joe Schmoe), then it's a worthless piece of crap. School is supposed to open your mind. Don't resist.

XP is just as worthless and just as worthwhile as PSP, FDD, RUP, CMM, Waterfall and any of the other approaches that have been developed over the decades. Programmer taste varies. So do the scope of the project, the constraints, the flexibility and flightiness of the customer, so do requirements (one particularly messy constraint). These all need to be taken into account when starting a new project. Then you need to perform risk assessment and decide what process will help you mitigate a lead developer getting hit by a truck, or your CVS archive getting eaten by the Halon system, not to mention feature creep.

Setting your mind on the One True development process is about as suicidal as making a career committment to a single programming language or hardware architecture.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

Right on (3.00 / 1) (#22)
by wiredog on Tue Apr 17, 2001 at 08:04:23 PM EST

I had a post that was going to say what you said, but not nearly as well. Fortunately the office router died before I could post it.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

Organization == Communication (4.00 / 1) (#9)
by slaytanic killer on Tue Apr 17, 2001 at 12:48:31 PM EST

All organization of people is about communication. Therefore you likely want to ensure that you have a really good sysadmin, who can set things up (or learn) quickly, so you can be very versatile in response to your newest communication needs. Make sure you don't overwork her; these people burn out fast, so you might want a helper, or at least make sure that she's not burdened with other duties while she's helping you design.

I have little to say about the formal n-stage processes you're curious about. They all strike me as somehow arbitrary; they're likely decent for large coordinations where they minimize everyone's energy tax, but as long as you have a sane one where the people who work with you are happy, and you don't cut corners, it shouldn't be that worrisome. XP programmers might take issue that Testing should be taken care of concurrently with Development, and so should Deployment and Requirements Definition...

Also, it might be important to have a reactive mindset, as in: What do we do when we have a new hire? Sure, these guys often take a while to get up to speed, so you might want to find ways to do it a little faster. That's one place where good planning comes in handy; you don't want someone waiting months for a trivial necessity like a functioning email address. (Which happens far more often than one would think.)

Another good link is Joel on Software. At the very least, it's a fun read.

BTW, I'm reminded of a Slashdot post on the "Sim-City process." It's probably suicidal when taken to the extreme unless there's a scenario where there's one really good programmer surrounded by not-good programmers. But it's fun to think about: Build the foundations/framework first horizontally, so that there's very minimal functionality; then have everyone build vertically on that. It was from his Sim-City strategy of building infrastructure like trains first, so that he had more options when dealing with the inevitable problems later in the game.

Poll problem (4.66 / 3) (#12)
by error 404 on Tue Apr 17, 2001 at 01:35:21 PM EST

None of the steps is the most important. What is important is the process.


..................................
Electrical banana is bound to be the very next phase
- Donovan

The best software company in the world (5.00 / 3) (#18)
by _Quinn on Tue Apr 17, 2001 at 04:35:07 PM EST

   (NASA -- at least, the part that writes the software for the shuttle) doesn't blame an engineer when it finds a bug; they are inevitable -- everybody makes mistakes. They fix it. But they don't just fix it -- they find out why it was made, and check other places where that same reason might apply, and work with engineers to reduce the chances of it happening again. Just as importantly, if a bug escapes -- gets flown -- they blame the process, and work to make sure that a bug of that type can't escape again: how did we write the bug? Why didn't we catch it? It's not just, how do we fix the bug, but how do we fix the process that /allowed/ the bug.

-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]
It depends. (4.72 / 11) (#13)
by jd on Tue Apr 17, 2001 at 01:43:07 PM EST

The processes you've outlined are one way of viewing a project. There are a few trillion others, which all have their merits and pitfalls.

The way I was taught to handle large-scale projects was to follow the Software Engineering software lifecycle, which was (roughly) described as:

Specification -> Design -> Reification -> Initial Implementation -> Testing (nth generation) -> Validation (nth generation) -> Bug Fixing (nth generation) -> cycle round to testing again

How to do any of the steps you outlined, without "doing the homework for you"? That's a touch challange, but I'll give it a go. :)

First, we come to planning. Planning will involve establishing what the problem is that you are trying to solve. If you're trying to develop an "expert system", or automate some manual process, you MUST be careful to avoid a common pitfall of assuming either you OR the other person knows what they're doing. Often, manual processes are instinctual or so automatic that the person is not going to be 100% aware of what they're actually doing. Your job would include deducing some of the requirements.

Requirements Definition - Once you know what the problem =REALLY= is (not simply what people =think= it is), you're in a position to say what the requirements are. In fact, it should follow. Most of this stuff does. Computing is not hard. But it's easy to =make= it hard.

Detailed Design - Depends on the problem and how critical it is to get the solution "right". A program to check if cheese is ripe is not as critical as an embedded controller in a nuclear reactor. The chief problem is this: Good designs will produce bug-free code. Simple designs will produce efficient code. Good designs are NEVER simple designs.

My recommendation here is to look at the nature of the problem, and place it in one of a number of categories, solving each category with the appropriate method:

  • Mission-Critical (a bug could cause significant damage, loss of life or some other significant loss): Use a formal specification language, such as Z. For something like this, you'd also be wise to go with the ISO 9000 standard.
  • Sensitive (a bug could seriously impair what you're trying to do, but failures aren't catastrophic): Again, you'd be wise to use Z, but don't bother with ISO 9000 compliance. The overhead isn't worth it, here.
  • Major (a bug will inconvenience users to the point where it's going to damage the company's image and may affect sales, but it's not going to be a disaster, even then): Here, a formal specification language is going to eat up time and resources for no perceptable gain. Getting it to work usably is more important than guaranteeing perfection. Structure diagrams are quick, easy to draw, and easy to code. Something like a Jackson Structure Diagram (JSD) would be great. Once you have a JSD, you can "expand" it into a Flow Chart, if you prefer working with low-level diagrams.
  • Minor (a bug will irritate, but nothing coffee won't solve. Nobody's going to lose any data, and in the scheme of things, nobody is even going to really care): Here, "detailed design" is actually redundant. You're actually looking for some quick sketches of the different sections and what data from your planning & requirements is applicable to what.

Iterative development and testing are essentially part and parcel of the same thing - the life-cycle of the designed software. Each generation is tested - often in a test harness, though also in the "Real World"(tm), and the results fed back to the developers to perform the next round of development.

Test Harnesses are one of the least-used, but most vital of ALL the utilities you will EVER use in software development. "Random" testing (ie: letting the user have a go) won't stress the product enough, in 99.9% of all cases. Users are unpredictable, and what they do one week, month or year, will often be totally different from what they do the next day.

Test Harnesses allow you to stress-test segments of the code, by force-feeding known inputs, and comparing the results with known outputs. This allows you to seriously put the code through it's paces, testing every imaginable combination of inputs and outputs, whether they make sense or not, or even whether they're allowable or not.

If your code survives a well-built test harness, THEN it's time to finish documentation. Finish? Yes! You SHOULD start documenting the program, the moment you start planning. Ideally, you'd start several days earlier. Documentation SHOULD contain a sketch of every stage of development, every major decision, every bug found & how fixed, and what you ate for breakfast. In short, each section needs to be brief, but you need a lot of them to be complete.

Deployment: Don't even bother, until the code has been stress-tested in a test harness which checks for valid, invalid and erronious data, and valid, invalid and erronious combinations of data. Once it's passed those checks - and the strictness will depend on the type of code, as outlined earlier - THEN AND ONLY THEN do you even consider deployment.

Once you deploy, that's it. You've now shown your cards to the users. If you skimped on the collection of requirements, mucked up on the specification, or put blind faith in a function as unnecessary to test, this is when you need to find religion. I'd also check prices at the local church. On the other hand, if you've been thorough and intelligent, so far, this section is plain sailing. Hand the code over, and/or install it on their systems, and you'll be fine.

Completion: No such animal. No matter =HOW= careful you've been, completion does not exist. It's a mirage. (No, not the French fighter, either.) Once you've handed over to the end user, you need to start looking for bug reports, support calls, users begging for extra bells & whistles, etc. These need to be fed back into the Detailed Design stage, so that you can check them against the constraints the design imposes, and those that can be implemented (within a reasonable cost) get specified, designed and implemented as above.

NOTE: There's an important word here -- constraint. Memorise it. This word is going to be your best friend, or your worst enemy. It's your choice, and it all depends on how you treat it. Constraints allow you to define what's allowable, where and when. This can be used in the test harness as part of the validation.

On the other hand, constraints ALSO confine you to what's allowable. Once a constraint is defined, it's going to be VERY hard to change, as it impacts every possible section of code the user can reach, and every possible path the user can follow. That's a lot of impact, for one piece of data. A bad choice can ruin your whole day.

Framework - Just about any book written on Software Engineering (the treatment of programming as a facet of the science of engineering) will cover this in depth. However, since each step IS a natural progression from the last, a formal treatment is often excessive. All you need is a book on formal (and informal) specifications, BNF grammers, and/or Jackson Structured Design. Again, comprehensive books aren't necessary. A pamphlet which gives you the complete syntax for all three, and some examples, would be quite sufficient for anything short of mission-critical, and even there, you could probably get along quite fine with that & a summary of ISO 9000.

Interesting subject, one that most companies ignore (which is why nobody offers any warranties on software!) and one in desperate need of discussion, IMHO.

(P.S. If companies, and Open Source coders, were to use even the most basic of test harnesses, on a regular basis, over 90% of all common bugs and 99% of all common security holes would not exist. Companies & OS coders avoid formal methods, largely because it's too much like class work, but also because it's cheaper to convince users that bugs are inevitable. Cheap psychology is often more profitable than quality technology. I'm just waiting for someone to sell the Emperor's New Clothes. I'm sure they'll make a fortune. People will notice and complain, but they'll buy in, just the same.)

Lost cause? (3.00 / 1) (#14)
by SlydeRule on Tue Apr 17, 2001 at 01:48:39 PM EST

I've been tasked by my boss to come up with a standard set of steps to follow when we start a big project. ... I do want to find out what works well for you.
Nothing works.

In the past twenty years, I've been on maybe a dozen software development projects. Those projects tried all manner of processes. The number which succeeded: zero.

In every case, the process was eventually discarded when it became clear that results were not being obtained. In some cases, that was years into a "crash" project.

One rather large company I once worked for found itself with nothing to sell when its old product line became obsolete and the requirements documents for the new product line still had not been fully signed off... over two years into what was to be a six-month project.

getting requirements early on (3.50 / 2) (#15)
by rebelcool on Tue Apr 17, 2001 at 03:57:37 PM EST

find out what the client wants exactly. If they start changing what they want halfway through the project (or after it's done), charge extra.

COG. Build your own community. Free, easy, powerful. Demo site

early requirements (none / 0) (#17)
by _Quinn on Tue Apr 17, 2001 at 04:28:06 PM EST

   There is strong feeling, from what I've read, rather than getting early requirements, that it's better to get more feedback. Produce early interface mockups and functional demonstrations; find out the client wants when they're really faced with it. Encourage them to critique mercilessly. In all fields, I find that most people can tell what's wrong with something, but that fewer people can tell you what's right -- so treasure them. (Even fewer people can tell you what's right without something. :)) Creation is always a more difficult process than critique, so ask the client to create as little as possible.

   This tight iterative process also means that you need to be very good about unit testing. Any part of the program which could conceivably be tested in isolation should be, and as exhaustively as possible; it will be working with different components in differnet ways as you revamp the system.

   Don't skip the design stage; it's more important, especially for knowing what to test, in rapidly changing systems than in relatively static ones. (That is, a good design will save you lots of time.) It will be short, in many cases -- but that just means it's easy to test. (In some ways, especially for a small enough task, the test suite /is/ the design.) Similarly, you should be documenting the sections you build along the way, at least technically.


   Of course, this doesn't work at all for problems on certain scales -- mission critical applications should have, as noted by other posters, the strongest possible formal definitions (and proofs, if you can) of the requirements and code involved.

-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]
PLEASE don't forget the *bigger* picture (4.75 / 4) (#19)
by tmoertel on Tue Apr 17, 2001 at 04:42:58 PM EST

Regardless of what kind of process model you use, here are a few important things that tend to get lost in the "methodology" quest. All of them fall into the category of people problems that are usually overlooked in software development processes. Despite their sideline status, these problems usually foretell of impending doom, so don't let this stuff slip between the cracks.
  • Require top-to-bottom communication. I don't know how many times I've seen programmers coding up implementations of business processes they really didn't understand. Likewise, I have heard business managers who knew nothing about software development making promises and decisions that fundamentally altered development constraints and jeopardized projects. Dumb stuff here. Place a coder or two in the business unit; let them live the business processes and freely communicate with the business folks. Sure, it isn't fun, but it is sensible. Make sure the business leaders are part of the development process. It's tempting to "keep the PHBs' meddling hands out of the software process," but in the end their business decisions influence the software process anyway. If their dumb decisions screw up the software efforts, let them at least see the fruits of their foolishness. Let them learn. Again, not fun, but beneficial.
  • Accept and respect reality. Never refuse to acknowledge unpleasant realities. Doing so allows small problems to grow into project slayers. How many times have you been in a meeting where a project's schedule was discussed and heard this kind of thing: "We're running two weeks behind on work that was scheduled to take four weeks. Let's agree to make this time up in the next development iteration. That means we'll have to do six weeks of work in the next four weeks. It's crunch time, folks. Okay?" Response: "Ah, yeah, okay." This is stupid. Guess how far behind you're going to be in four weeks? Do you think it will be easier to make up four weeks of work then? Accept the unpleasant reality: The initial estimates were too low by about a third. Adjust the schedule accordingly. Let the business folks know and take the heat. Better to take a little heat now than a lot later.
  • Resist foolishness, in all forms. If you notice that something foolish is going on, stop it. Immediately. Raise the red flag. If the project manager thinks that he can compress the schedule by dragging bars around in Microsoft Project, stop him. Schedules only reflect reality, not dictate it. If the programmers think that they can save time by skipping unit testing, stop them. The endgame of most projects bogs down in unproductive debugging, much of which could have been avoided by good unit testing. If the business leaders think that they can halve the project schedule by simply purchasing SilverBullet X, stop them. They're being suckered by some vendor's sales reps. Too many projects have died because people who saw the birth of foolishness allowed it to grow and flourish. Be ever wary of foolishness, and when you find it, crush it early.
All of these things sound like common sense, but for some reason when it comes to software, common sense is left behind in the race to acquire the latest fad methodology, CASE tool, language, and so on.

Software development is hard. Checking your brain at the door only makes it harder.

--
My blog | LectroTest

[ Disagree? Reply. ]


three important stages (3.00 / 3) (#20)
by dr k on Tue Apr 17, 2001 at 05:03:12 PM EST

You left out the three most important stages:

- Planning to plan : have a meeting in the "big" conference room with everyone who is available. Write down lots of stuff on a whiteboard, and put "do not erase" in the corner.

- Kickbacks R Us : Call up your favorite software vendor and arrange for a demo of their latest CMS solution. Don't forget to ask the vendor for a "referral bonus", if your company actually buys the software.

- Fire your consultant : Get rid of that overpriced consultant who only knows how to use the "wizards" and hire two or three interns instead.
Destroy all trusted users!

I second that ... (none / 0) (#21)
by MoxFulder on Tue Apr 17, 2001 at 07:57:31 PM EST

As one of the interns who is coding the pants off the stupid consultants, I couldn't agree more! :-)

"If good things lasted forever, would we realize how special they are?"
--Calvin and Hobbes


[ Parent ]
What planning? (3.00 / 1) (#23)
by decaf_dude on Wed Apr 18, 2001 at 05:29:50 AM EST

Real men code everything first, then realise they delivered a piece of shit that does nothing really useful and nobody really wants or needs, spending huge amount of money in the process.

At least that's how we work here :)


--
http://slashdot.org/comments.pl?sid=89158&cid=7713039


Lot of work ahead of you (5.00 / 3) (#24)
by tchaika on Wed Apr 18, 2001 at 02:06:46 PM EST

It's good that you have good intentions, but beware this is a huge task that is facing you and your organization.

In short: you will fall on your arse if you try to do this yourself. (sorry!)

The reason - managing a software project properly (something rarely achieved, but what you are striving for) is a complex task that takes a fair amount of training and experience. You can't just get it out of a book (although there are many excellent books on the subject). It's the equivalent of putting someone who doesn't know accounting in charge of running the company's finances. You are at the stage where you do not know what you need to know - hopefully this will become clear.

Two books I can recommend to give you an appreciation of what you are in for:

Software Project Survival Guide (contains lots of checklists to assess the project and how well it is doing, spot warning signs, etc).

Rapid Developement (it's mostly not about rapid development, it's about all the fundamentals needed to get a development team to working well enough to start doing rapid development).

These are some fundamental heuristics to help you on your path:

1. Divide and conquer - keep project phases, designs, code, and everything else in the project short and sweet and therefore, more easily manageable. If anything is too big, break it down.

2. Track your progress according to clearly defined goals and adjust those goals regularly so they stay realistic. Don't set fixed deadlines ever, because you never know exactly when a project will be finished. At first, target a particular quarter, and as you get more information about requirements and your team's performance, narrow it down.

3. Get requirements by using Use Cases or some similar methodology. Translate these into a design then implement the design. Expect and allow features to change with user feedback. Never try to sign of any particular project phase and not revisit it.

4. To avoid dooming your project, make sure your project sponsors have a clear strategy for using the system and a clear understanding of how the system will meet that strategy. Make sure that everything in the requirements is in accordance with this. Or else, you are doomed to scope creep and delivering a system that no-one really wants, because they never thought properly about what they want.

5. Test, test, test. Write unit tests, and run them all as a batch job every day. This is your regression test to prevent introduction of new bugs. Write functional tests.

6. I hate to say it, but you need a consultant, at the least (better, a permanent staffer), to design and implement a suitable project management framework, and make sure it runs properly. You cannot achieve this by yourself, and if you do, it will be a stunt - this is not sound management.

7. Plan ALL the tasks on the project. If you don't know how long some of them will take, guess, and revise as you get more information. Make sure that everyone will have the resources they need on the day they are meant to accomplish a given task.

8. Assumption is the mother of all f***ups.

9. It is about 50 times cheaper to fix a mistake in the requirements phase than after the system has gone live.

To summarize:

A project must be bourne from a good strategy.
Requirements must be developed in accordance with the strategy.
The system must be designed to accomdate the requirements.
Code, infrastructure, etc must be implemented according to the design.
Any breakdown in the links between these elements (e.g. coders going off and writing ad hoc code modules based on what some user told them) is where your project risks going haywire.

Capability Maturity Model (4.00 / 1) (#25)
by Paul Johnson on Thu Apr 19, 2001 at 07:03:30 AM EST

Take a look at the Software Capability Maturity Model (SW-CMM). Its about process improvement.

The big problem with detailed processes of the sort that you are expected to write is that they always say what people think they ought to be doing, rather than what they actually do or what actually works. The CMM is about avoiding this trap: you collect metrics and continuously revise your processes in order to improve them based on experience. Thus if there is a discrepancy between what the process document says and what is actually done then you don't bludgeon people over the head with the document until they do it "right", you look at both the document and the practice and decide which one is better. Then change the one that is wrong.

The CMM defines maturity "levels" where Level 1 is disorganised and success is due to luck, and Level 5 is continuously optimising itself based on clear metrics which are understood and respected by all involved. But there is also a "ha ha only serious" Capability Immaturity Model which defines Level 1 as knowing that you need to improve, and adds Level 0 to Level -3. Dilbert works for a Level -3 organisation.

One thing that you need to avoid when writing your process documents is moving from Level 0 (Negligent) to Level -1 (Obstructive), where

These organizations insist on complex processes, involving the use of arcane programming languages, outdated hardware and COTS products, and inappropriate documentation deliverables. Level -1 organizations deploy significant effort and a substantial portion of their human and dollar resources in order to impose these inappropriate processes and products across all projects for all software development no matter how large or how small. The unsuitable software processes have no owners and no method for changing the processes, and in fact modifications to the existing processes are actively discouraged.

Paul.
You are lost in a twisty maze of little standards, all different.

From my experiences... (none / 0) (#26)
by dreamfish on Thu Apr 19, 2001 at 09:02:37 AM EST

The one golden rule I've found vital in project planning (and frequently ignored in a number of projects I've worked) on is at each stage include plenty of contingency.

Software development is far from the exact science a lot of companies like to think it is. It's difficult to measure 'progress' and further complications arise in compoinent interfacing and application of new and immature technologies, especially when they're seen as silver bullets.

There's an old adage in IT projects that you calculate the timescales and then multiply them by three. Obviously that's a little trite and doesn't help if you've got a fixed deadline (even if the deadline was set by the marketing dept.). The best approach is to do some risk analysis and add generous contingency to the schedules of higher risk tasks.

Projects HOW-TO | 26 comments (24 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!