Programming with
a dose of satire.
Lifecycle
|
| ||||||||
 |
 |
|||||||
|
Lifecycle |
||||||||
Ten Golden Rules to Prevent Your Project From FailingBy Matt Stephens Most project managers seem to be interminably busy. They regularly take on much more work than they can comfortably manage, and forget to delegate. As a result, their work is much less effective, and usually prone to error. This in turn makes them progressively busier and even less effective.
Bearing this in mind, the managers who most need help - the busiest ones - are by definition the ones who believe they don't have time to improve. It's like giving a child a "how to read" book, and letting them get on with it. And so (assuming the busy managers have had time to read through this introduction) here, fermented down into one bite-size section, are the ten golden rules for running a successful software project. Don't forget to add your own thoughts, in the Talkback section at the end of this article.
The Ten Golden Rules for a Successful Project Each of these items could start with "Above all else, remember this: " They are mostly common sense, of course. If you don't do any other sensible things, at least follow these rules. If you neglect even one of these items, your project will probably fail. Oh and one more thing, before we launch into the actual rules: these are not "set in stone". They're a first stab at producing something that can be of genuine benefit to managers and developers everywhere. Over time these rules will evolve, depending on your feedback. The rules themselves may be "swapped out" and more important rules swapped in. They are not by any means the only rules: they are simply the ten most important things to remember...
1. Listen to your staff. Trust their judgement, especially the clever ones. 2. Beware of projects that have a deadline set in stone, 3. The project plan does not shape the project's timescale: it measures it. 4. When planning, don't forget to take into account the usual delaying factors ...
5. Trendy development methodologies are a symptom of a greater ill. 6. Never be afraid of the customer. 7. Always have a contingency plan: don't put all your eggs in one basket. 8. Beware of round numbers suggesting an infinite amount of time remaining.
9. If you must panic, panic early. Better still, don't panic. 10. Late nights and pizzas do NOT make a project run faster!
So there you go. There's bound to be ultra-important stuff that I have left out. The above ten items mostly stem from factors that I have seen to actually cause projects to fail. I'm sure there are many more. Please feel free to use the Talkback section on this page, and add your own thoughts. Use your own experience to help further shape and refine these rules, and make them the number one authority for successful projects!
Links and resources on the Web
The above rules are the ten most important (probably). Of course there's much more common sense to be learned, and luckily there are a lot of websites and resources out there with exactly the information you need, just begging to be read and used. Here's a selection: 4pm.com
SoftwareProjects.org
Talkback: Have Your Say If you agree, disagree, or have some golden rules of your own to add... why not leave a message here? Message Index:
The Messages: My thoughts [part 1][Posted in 3 parts due to 2K message limit] The first step is to admit that improvements are possible. Work smarter, not harder, i.e. donīt equate loyalty with blind obedience and insane hours. Rule 1) Yes, esp the clever ones, who will appear more bolshey and opinionated. Being right tends to do that to you. The staff are not there to make you feel good and nod through all your musings, they are there to make the project succeed. They cannot have 2 masters. Rule 2) And if the mandatory items are still too numerous or onerous to do in the given time, then have the balls to speak up. Stop trying to please all your bosses by telling them what they want to hear. Its better to tell them in the beginning that it wonīt happen than the day before its due. "I didnīt tell you then else youīd be angry for 6 months, this way youīre only angry for a day". Rule 3) And remember, most everything takes longer than you think. Beware of bullying staff into lowering their estimates, e.g. "How long will this take? Oh no, that number is no good, make it lower. Its ok, I wonīt hold you to it... (X Months later) But you promised it would be ready by now!!!!!" Dino dino@felstar.com Epsom, UK Mon Jul 30 06:56:49 EDT 2001 part 2 Rule 4) Especially if it is something they have not done before. Its hard to measure something that you have never seen. Basic stuff like "add 3 tables to db" is a lot easier to estimate than "handle fx execution" which means everything and nothing. Also measure the measurer. If a newbie programmer of one year tells you something, it may be a lot less accurate, and more optimistic, than the words of a programmer of 10+ years. Experienced programmers tend to be cynics. This does not make them popular. Managers want optimism and drive, the bright "can-do" attitude of ignorance. "Vikram doesnīt know the meaning of the word īNOī". Oh yes, make sure they can speak English, as well as avoiding those programmers with a pathological desire to please and appear knowledgeable. The truth is very important in projects, we need to stay grounded in reality. You need people who will tell you when the emperor has no clothes. In fact experienced programmers will save many a project simply from saying a big NO to the multitude of silly ideas that might pop up. There is only so much work that can be done, and avoiding wild goose chases helps the project focus. There is no point running off, fast, in the wrong direction, even though it does give a lovely warm glow of illusionary progress. Rule 5) And a basic question is: Do you have a functional spec? And a design spec? Are you one of those "special" projects that doesnīt need one? Do people in your organisation see specs as old fashioned? If so, run away!!! Rule 6) A company that is desperate for work will often give up on this stage, just turning into a nodding dog to whatever they say. Rule 7) Also, cost the project. Will it cost more to run than you are getting paid. No point being on schedule if it bankrupts the company. Rule 9) Yes, get the natural fear associated with any project over early. Do all the hard thinking NOW. Dino dino@felstar.com Epsom, UK Mon Jul 30 07:01:38 EDT 2001 part 3 Rule 10) Yes, and hire smart people. You canīt polish a turd, and getting dumb people who refuse to learn new languages and technologies themselves and ītrainingī them wonīt make them smarter. It just changes the wrapping. There is very little place for dumb people in programming. You have to ask yourself, what part of your project do you want to be done badly? If the answer is none, then make sure all your people are good. Avoid political restrictions, like "we donīt hire contractors". Get the people to do the job, your project isnīt a hobby to keep your permies feeling wanted. If they donīt have the skills or experience, hire some smart people to top up your project. You canīt run a car on milk, you need petrol. Your fridge may be full of milk but thatīs no excuse to fill your car with it. Avoid any programmer who doesnīt have a website now. If they donīt LOVE computers donīt have them. Todayīs demanding projects require people who like their job, not 9-5 people who do computers because they couldnīt be a fighter jet pilot. Better to have 4 people of 75 an hour, who are really on the ball, than 8 people on 40 an hour who are basically very average, do what they are told to an extent, and have no real judgement on whether what they are being asked to do is sane or possible. Just because you have a permie that works from 9-9, showing utter keenness, doesnīt mean they produce good work. In fact if they work long hours it normally means they are out of control. Beware projects that require evening/weekend work. Beware any macho bull*@!#. Sure, it may hurt your ego to pay those "greedy" contractors, but look at the results. This is not to bash all permies, just saying that if your permies are not up to the task at hand, donīt be afraid to inject some freelance wisdom. As I like to say, "if you think Iīm expensive, try hiring an amateur". Or as the chinese say, "buy best, cry once". Dino Epsom, UK Mon Jul 30 07:09:22 EDT 2001 some golden rules more general version: triangle management: resource/capability/time You can´t fix all three. Know which are fixed & negotiate how much you can change the other(s). Regards Howard howard howard@oddenhillfield.demon.co.uk Not sure where exactly, UK Mon Jul 30 15:22:44 EDT 2001 Squeeze that balloon ! Yes Howardīs triangle is like trying to squeeze a balloon. As soon as you squeeze one part, another part just expands to accomodate the air. Likewise with a project plan you canīt fix time, work (person-hours) AND resources. Something has to give. Bill J. Land of Hope, UK Wed Aug 01 05:20:40 EDT 2001 If you have a problem sleep on it! More for the managees rather than the managers: If you are stuck on a problem, don´t keep working on it through the night. Get out, enjoy yourself, have a good night´s sleep and you´ll wake up with the solution in the morning. Your subconscious is a lot smarter than your conscious brain. Chris Burrows CFB Software Chris Burrows info@cfbsoftware.com Adelaide, Australia Wed Aug 01 21:58:26 EDT 2001 Recommended book ´The Inmates are Running the Asylum´ by Alan Cooper SAMS Publishing ISBN 0-672-31649-8 Chris Burrows info@cfbsoftware.com Adelaide, Australia Wed Aug 01 22:06:21 EDT 2001 Use the 80-20 rule If you have more to achieve than is possible with the resources available, apply the 80-20 rule (most recently seen in a book about Prof.N.Wirth) i.e. identify the 80% of the task that can be done in 20% of the time and focus on that. Chris Burrows info@cfbsoftware.com Adelaide, Australia Wed Aug 01 22:14:13 EDT 2001 Assign non-techies to software projects Non-techie execs should liaise with the technical project manager, to make sure requirements are being met through every phase of the project. Chris Kist MA, USA Fri Aug 03 10:07:37 EDT 2001 Rapidly Changing Requirements Rule Five says: īSorry, but itīs true. If a project has "rapidly changing requirements", then thereīs something very wrong. Maybe the customer needs to be educated. Manage this dangerous scenario properly. Donīt see it as a challenge, see it as a threat that must be eradicated at the source.ī Have internet years been invented where you are? People want to change their minds. People want to start projects before they know everything about what they want. People want to say "Iīll know it when I see it". If you can get fixed requirements, go for it. But fixed requirements arenīt working for a lot of people, and the reaction of forcing them to be fixed isnīt helpful. It turns out that it is possible to develop software quite well in the presence of changing requirements. A lot of people are finding it quite useful, as well as fun. Ron Jeffries ronjeffries@acm.org Michigan, USA Mon Aug 06 12:55:28 EDT 2001 Re: Forum: Ten Golden Rules The Ten Golden Rules are so true, but one important rule is missing: 11. "Tell me lies, tell me sweet little lies" Youīll never lead the project, unless you ignore at least some of the aforementioned rules. Upper management prefers īpromisingī project leads. Hard truths make upper management sleep bad for a long time. Faking keeps their nerves healthy. The bad manager distributes nerveous problems fairly among his team. Weeks and months later, there will be plenty of good excuses ;-) L. U. Jasogi lujasogi@hotmail.com Southpark, GE Mon Aug 06 14:57:02 EDT 2001 re: Rapidly Changing Requirements Argh, best go to the XP forum if you want to start on that stuff. Oooh, I feel dirty even mentioning XP. Dino Not sure where exactly, UK Tue Aug 07 13:51:19 EDT 2001 re: Rapidly Changing Requirements >Have internet years been invented where you are? Internet years, meaning "this project must be completed at lightning speed"? Thatīs the time when discipline and common sense matter the most. Ignoring these rules will just delay the project. >People want to change their minds. People want Yes, people are people. Fickle customers are the worst kind. They often mix business needs with shiny "nice-to-haves" (mixing business with pleasure?), and have trouble telling them apart. Business requirements tend to be [relatively] fixed; nice-to-haves change every time the customer gets a new idea. >to start projects before they know everything >about what they want. People want to say "Iīll >know it when I see it". And thatīs where you come in, as the consultant. Prototypes, mock screen-shots, storyboarding - these can all help the poor confused customer to visualise what they want, before a single line of production code is written. This doesnīt mean requirements should be fixed: thatīs the other end of the scale, which is equally bad. As long as the project plan is kept up-to-date, and the customer is made aware exactly how much their new idea will impact the timescale - i.e. (shock horror) tell the customer the truth - then changing requirements can be kept under control. Matt maffstephens@lycos.com London, England Wed Aug 08 06:35:17 EDT 2001 Educate yourself in the problem domain Rule: educate yourself as a PM in the problem domain. Know what your users do, know where the company is heading, know the problems programmers may encounter, etc. Then you can make educated and informed decisions. BTW, requirements do change. If you haven´t done it before, it´s best to assume your requirements are wrong. If one can´t deal with it, PM is probably not the best job for you. Bas bas@softwareprojects.org Amsterdam, The Netherlands Thu Aug 09 14:55:51 EDT 2001 Perform Theory W The last paragraph on my previous posting was a bit too early, didn´t read it all, I agree with the answer to "Rapidly Changing Requirements", just one posting above this one... sorry for that. Golden rule: make every one a winner! It´s a rule from Barry Boehms Theory W on Software Project Management... At the end of the day, it´s still the best advice. Bas bas@softwareprojects.org Not sure where exactly, The Netherlands Thu Aug 09 15:03:29 EDT 2001 re: Use the 80-20 rule >identify the 80% of the task that can be done in >20% of the time and focus on that. The antithesis to this is "Do the most difficult stuff first". If the project is "80% complete", the remaining 20% will probably take 80% of the overall project time. Developers (damn their rotten hides) tend to put off the tricky stuff until they absolutely have to do it, and will concentrate instead on the easy, fun stuff - unless you kick them (us) into solving the real problems first. Matt maffstephens@lycos.com London, England Fri Aug 10 08:16:07 EDT 2001 Rule 13. Avoid Politics As the rule states: Avoid Politics. If you canīt avoid politics let the customer worry about it and state that this part of the project cannot succeed unless the barrier imposed by the political problem is solved by THEM. Never ever solve it yourself, however you could do worse than to call every party in a meeting and help them sort it out. Most often political problems will be solved if the parties involved understand eachother. Matthijs Claessen empire@cistron.nl Delft, The Netherlands Fri Aug 10 10:50:37 EDT 2001 Zen and the Art of Project Management Matt, Well, I am not sure I subscribe the dumb customer theory of management. I have seen all too often that the customer knows exactly what they want. The problem is that it usually doesnīt fit into our quasi-standardised world and almost certainly wonīt involve our favourite piece of middleware. I think you get my drift :o) Another thing I have found baffling is regarding project scope. Lots of emphasis on prioritisation and the like. If you have decided that an element of functionality can be dropped when push-comes-to-shove, then for heavens sake drop it at the start of the project. Start a project with only those things on the list that define a usable system. Quality is not defined by how cool a product is, but how well it matches its intended purpose. Subject meets objects - anybody read īZen and the Art of Motorcycle Maintenanceī? Oh yes, I nearly forgot, my favourite: I would rather run a project with too few staff members rather than too many - with the caveat that the skills base is there. Too many projects are over staffed - IMHO. Iīll be back as I am sure Iīll think of more - hehe. Antony Hirst antonyhirst@bigfoot.com Farnham, Surrey, UK Thu Aug 16 11:24:13 EDT 2001 Random ramblings ...culled from the years: 1. The amount of work in a project is fixed, though you only know how much there is (was) once it's done! 2. Estimate, using experience, each work area and be cautious about anything new / unfamiliar. 3. Find the problems / uncertainties early & start on these first. Get working prototypes going. (Imagine trying to do this near project end, not at the start..) 4. Try to make progress both "top-down" and "bottom up". Top-down can be shown to managers (e.g. a demo of a GUI) whilst the nuts and bolts are also progressed. 5. Teach your staff that documentation is a glue used to keep the project working as one. Documentation is a framework, giving structure and linking people (like linking neurones in a brain). 6. Talk to your staff and show them your view of the way forward, what the timescales are; explain the issues, where we are now and what we need to do next. Get feedback and fold it in. 7. Use reviews; be careful with egos though. Focus on helping the work forward. 8. The greatest known team motivator is.. humour! 9. Aim for 80% staff workload; this paces people, gives a nice working environment & creates margin for those little calamities in & out of work. 10. Balance this with planned "surges" - an intensive working week, when there is no crisis on. This gives variety, changes tempo, establishes the higher work pattern and gains a lead on timescales. An early-on trick. 11. Quality is the "timely and economic delivery of apt benefits of ownership". 12. This hinges on "benefits of ownership". So what's your customer's perception of this? What are the benefits they expect to have when they take delivery? Will your work deliver these? 13. Understand Verification & Validation, testing using the V-diagram. 14. Configuration & build control... have some! (centrally recorded, please). 15. Problem reports. Let anyone raise an "observation", get each assessed, prioritorised & progressed. 16. Find out what people are good at & what they want to do next. Give people jobs in both areas (so you get progress from them & they feel they're improving their skills). If you can, pair experts/learners. This also provides "skill shadows" (guards against the "run over by a bus" threat). 17. Use diagrams, charts, draw things. People remember these well. 18. Simplify. Even complex issues can be chopped into small, simple pieces. Modules / objects can be helped this way too. 19. Studies (TRW, early 1980īs) have shown that a key quality of code is "transparency" - it's legibility, i.e. the ease with which a 3rd party could pick the code up & understand it. Simple, transparent code is easy to maintain, usually compiler-optimises well, is relatively small and quick. And definitely has less bugs as the developer can see what they're doing& 20. Use naming to map program components into the problem domain to aid transparency, so code reads as English e.g. eyecolourof (alice) = blue etc. 21. Do BCS part II. This has a lot of useful management stuff (e.g. the mantra Plan-Organise-Monitor-Control) and is definitely worth the effort. 22. Get an agreed minimum set of features working first. Once theyīre done, then work on the extras and "wouldnīt it be nice if"s. Whew .. enough. Good job that this is all a game! (and, that if it was easy, they wouldn't have to employ us!) Steve Broderick brodders@mcmail.com Ipswich, England Wed Aug 22 12:01:37 EDT 2001 A Variation on Triangle Management A variation on Triangle Management (e.g., triangle management: resource/capability/time): You have three options--A project can be completed on time, can be completed cheap, or can be completed good/well/high quality. You can choose two of the three options. Dean Costello costello@earthlink.net Washington, DC, USA Wed Jan 02 15:07:31 EST 2002 Managing more than the triangle Lots of folk try and manage the triangle of cost / timescale / quality, but as several posts have already pointed out, we also need to manage scope in that same set of trade-offs. Think of a reservoir filled with an incompressible fluid, with four plungers on it. Any time you push one down, the other three are going to move back up... Gordon Love xlucid@users.sourceforge.net Edinburgh, UK Fri Jun 20 01:00:32 GMT 2003 Rule: Don't stick to much to rules I learned over the years that one of the most important things is to not just follow rules, or let's say the ideal 'how it should be' guidelines you find in books, etc... Instead one needs to reflect over the current situation and act on it. Altough this seems obvious... I've seen people trying to design/manage software using methodologies as RUP, XP, ... and instead of making common sense decisions they just follow the process. In reality there is no solution that fits all, only common sense will do the trick I'm not trying to say here that methodologies, analysis-architectural-design patterns(i use them all the time where they make sense), etc... aren't usefull. Just don't fall in the trap of using them because you are supposed to use them. David Reyntjens david_reyntjens@hotmail.com belgium, belgium Tue Aug 26 16:25:43 BST 2003 Three rules is all I need I long ago created "Salt's Three Rules for Project Success". They are: 1. Do the things that need doing, in order. 2. Don't do the things that don't need doing. 3. Try not to be incredibly stupid. Very few companies I have seen develop software manage to stick to all three. All the best, John. John D Salt jdsalt@gotadsl.co.uk Risca, South Wales Sat Mar 06 20:05:13 GMT 2004 The wisest words I have ever seen Many moons ago, I worked for a company that was hopeless at programming (good job it was just a sideline for them). Anyway, I went to visit a client once, and on a wall was a piece of paper on which were scribbled the words: "Get it working first. Tart it up later". Now there's advice that you can take to the bank! Mark Carter mcturra2000@yahoo.co.uk Turriff, Aberdeenshire, UK Sat Jul 31 11:21:49 BST 2004 |
||||||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright Đ 1998-2007 Matt Stephens. ALL RIGHTS RESERVED.