50 Comments to “Agile Software Development Project vs. Standard Software Development Project”

• June 12, 2009 at 9:30 pm
  Ryan Martens says:

  Brad,
  It is hard to prove you wrong in a post, but my argument would go as follows. If it were perfect, they would both spend the same time, but in agile your risk profile would have gone down steadily. That is worth a ton and would have kept the business from goofing with the project.

  However, by constraining the problem to perfect requirements and a project where the software is done at the end of the project you have created a false dilemma by taking all the humans out of the picture and future maintenance.

  So let’s say this is just water flowing through a pipe. A good agile team would have work stories in small batches with very little Work-in-process and batching. As a result, the communications overhead would have reduced and the flow have been smoother. If it was just water, it would have flowed with less friction or waste.

  A good agile team would have shipped the highest value, and potentially useful components first and allowed the business to start gaining value much earlier; Thus increasing ROI.

  Finally, the agile team might have learned that all the business value was delivered after 4 cycles and not built the last cycle of work. By ending early, they could have leveraged the 80/20 rule. The structured waterfall team had no chance to do that.

  I hope my three scenarios gave you some strong reasons to question your theory. With regards to proof, do not miss the agile impact report on our web site. 50% faster and 25% more productive with agile and Rally. http://www.rallydev.com/downloads/document/103-the-agile-impact-report-proven-performance-metrics-from-the-agile-enterprise.html
• June 12, 2009 at 11:30 pm
  Richard Leavitt says:

  ROI is a project’s story of its cash flows over a specific time interval. The fact that Agile delivers (smaller) pieces of value earlier has a really big impact on all aspects ROI: you hit self-funding sooner, so you invest less. You hit break even sooner, you reach profitability sooner. Typically these returns hold up over time and waterfall never catches up.

  A spread sheet tracking 12 months of project costs and benefits for both models readily shows these advantages.

  But I’ve found finance people care MOST about reduced risk of losing their sunk costs. Again, when you are trying to decide which projects to fund, risk-adjusting your return makes Agile projects trump waterfall every time.

  I just presented this financial story at Better Software. Happy to forward the deck. I believe they are supposed to post a video of the talk as well…
• June 12, 2009 at 11:39 pm
  Brad Egeland says:

  Richard & Ryan – Thanks for the followup comments – this is exactly what I was looking for in the discussion. I can certainly understand the cost savings over the long haul as there is far less likelihood of developing an un-useable solution…which happens far too often with the waterfall method. (I referred to it as ’standard’ to basically cover all things not Agile). I was just trying to understand that if all things were perfect on the project and you managed it both ways – would that one isolated project be cheaper through waterfall. Knowing, of course, that that is hard to attain (a perfect project with waterfall) and that it wouldn’t hold up over a portfolio of projects.

  I had a nice discussion with Kris G. at your both on Wednesday just before lunch and then decided to write this article when I got home from the Expo. Thanks again for the comments and insight. I would very much like to see that deck – please send it to me at brad@bradegeland.com if you don’t mind. Thanks again.
• June 13, 2009 at 12:33 am
  Manuel Monteverde says:

  If everything went perfect I think you might be able to deliver the whole application a bit sooner with standard software development. This is because you reduce a lot of the meetings that go on with agile software development. So at the end you spend less money.

  With Agile you get a lot more benefits but assuming a perfect scenario and involving only budget I would go with traditional software development. Even thou I know this will probably never happen in real life situations.
• June 13, 2009 at 2:07 am
  Marcos Orozco says:

  Brad, I read your comment, and I think you start with a confusion about the process for standard project management and the life cicle of software projects. The standard process of project management include the agile vision, but few people know it.
• June 13, 2009 at 6:43 am
  Brad Egeland says:

  Marcos – what may be considered standard process for project management on a software dev project and what is actually practiced are two different things…like you basically said. I’m looking at it more from what standard practice seems to be and what I’ve experienced in organizations through the years. And it’s certainly not been anything very close to the Agile method.
• June 13, 2009 at 6:59 pm
  allan kelly says:

  Of course in your “perfect world” the cost is less! But your definition of “perfect world” is defined as a world in which “standard processes” deliver a lower cost outcome.

  Your “perfect world” is therefore weighted to the standard process. If your standard process doesn’t deliver the lower cost outcome then you will just redefine the perfect world.

  What you call the “standard process” usually goes by the name “waterfall.” The paper that introduced this model (Royce, 1968) was also the paper that discredited it. Unfortunately the bit that was remembered and passed down the generations was the first page.

  Lets assume the perfect world into existence:
  - requirements can be specified up front (we have perfect vision)
  - design can be done up fron (we have perfect knowlegde)
  - software can be developed from the two above
  - testing shouldn’t be needed because we have perfect foresight and perfect design so surely implementation should be perfect too
  - the software will meet the business need perfectly and deliver the benefits perfectly

  So there is no risk to the project.
  As there is no risk to the project there is also no value. It is a basic tenant of economics that profit is the reward for risk.
  In the perfect world there is no risk so how can there be profit?

  Also in this perfect world: GM makes money and banks don’t need bail outs
• June 13, 2009 at 11:39 pm
  Brad Egeland says:

  Alan- If you read my post carefully, I make sure I say in several different ways that the ‘perfect world’ I describe is about as likely has hitting the lottery. I merely wanted opinions on a scenario that if the requirements were dead-on in both scenarios then I would think the waterfall method would end up being cheaper due to less overhead, etc. I still believe that to be the case…but 18 years of project management tells me that the perfect world never really exists and just as many projects die in the middle as do finish successfully.
• June 14, 2009 at 4:19 am
  Matt Perez says:

  “All things” are NEVER equal. That’s the point of using Agile methodologies. “Perfect world” is always quoted because it doesn’t exist.

  Agile is not a panacea, either. You can screw up with it just as much as any other. Experience still counts.

  The point of it all is to improve the odds towards success by doing the reasonable thing: break things down into chunks that mere humans can handle; start little and build on it (iterate); stay flexible so can you go to where the market wants to take you.

  Here’s a tale of two start ups we worked with: one was Agile (throughout the company, not just in development) and the other was not. One is going strong, the other went to limbo. You can guess which is which, but if you want to read about it look here http://nearsoft.com/a-tale-of-two-startups
• June 16, 2009 at 12:02 am
  SQE Better Software Development Expo Findings | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] was definitely toward Agile Software Development which, in part, prompted my post last week about Agile vs. Waterfall software development and the costs associated with each [...]
• June 17, 2009 at 2:19 am
  Roberto Martinez says:

  Brad,

  Of course you know that…
  If we were to take a large software project and run it both ways – standard and Agile – and then let’s assume that both work perfectly…no re-work, no missed requirements, etc. At the end of each version of the project, what shape would the budget be in?
  … does not exist in real life.

  Both will cost the same :-). But… here is my experience with both of them. In a large project, requirements change over the life of a project, in a standard project you never re-prioritize and end up delivering obsolete products. Agile in practice re-prioritize in every sprint, which means your will deliver what your users will use.
  Take the people out requirements will still change affected by external factors (technology platforms, regulations, etc).

  So, even if both have a “perfect” situation, re-prioritization will save the bullet. Remember having 2-4 week sprint does not mean you do not have the big picture of the product. It is just that time has teach us that changes will come and we need to inject them in the product.

  In standard projects users are the “enemy”, if they come with changes we need to hide from them because that means to say NO or extend the life of the project and not launch.
  In Agile users are your champions, they will “build” the product.

  There is much to say, but just think Agile is the evolution of software development processes.
• June 17, 2009 at 8:49 am
  George Brooke says:

  Hi,
  on the (big) assumption that both approaches work, the traditional approach will be cheaper. Agile however, in the real world, takes into account the variability of customer’s expectations and the various misunderstandings of the analysts/developers. A rule-of-thumb is that the higher level of risk, the more you need to make visible in the development process .. that is, the more iterations and kicking the tyres you need to do. For those (occasional) low risk, done-it-before projects, the cost of iterations, heavy customer involvement and so on, can be reduced (probably never to zero however).
  There needs to be more discussion about suitability of types projects to Agile and other techniques. It is not a one-solution fits all. Try an Agile approach on extreme products like a chess-playing program. Where are your 2-week iterations then? Agile works well for transaction-type applications – broad but shallow ( in terms of complexity of analysis). When the processing gets heavy or complex (as in Chess), there needs to be rather more analysis than can be fitted into the typical snappy iteration. Elements of Agile, which itself is a collection of best practices from traditional development, can always be used, waterfall or not. In particular, frequent integration, daily builds, continuous testand so on.
  I suppose the subtext to the question is “what makes an Agile project?”. How much of the Agile shopping list can you leave out before someone says, “Hey, this is not Agile”. AINO, Agile in name only? generally, Agile is taken to mean non-waterfall.
  While we are on the subject, we should keep in mind some prerequisites for Agile projects.It would be foolish to start on a (fully) Agile project when we do not have, for example, multi-skilled team, good access to customer and users, predefined architecture, well understood tools and so on. Anyone got a prerequisites list?
• June 17, 2009 at 11:42 am
  Varadharajan says:

  Brad,

  You have considered Post deployment support which I think would be a longer duration in a “standard” project as against “agile” since the users would start getting trained / use the software after the entire available has been developed. In case of “agile” development, the training would be a parallel activity and the users would be using part of the product even before the entire product is available. I think that would definitely be a cost / time saving. What do you feel ?
• June 17, 2009 at 9:47 pm
  Lance Walton says:

  Hi.

  What is it about ‘Agile Software Development’ that would prevent access to the perfect knowledge or prohibit perfect execution such that it would not do at least as well as the ’standard’ process you describe?

  Regards,

  Lance
• June 17, 2009 at 9:56 pm
  Brad Egeland says:

  Lance- Absolutely nothing. In fact my whole article agrees that it is logically far more likely to achieve project success using Agile vs. standard or Waterfall methods. I was just trying to understand if both are run perfectly wouldn’t the costs under Waterfall for that one project be less due to less overhead, testing, etc. I think they would be, but the long-term success over many projects would likely be much higher using Agile for your project portfolio.
• June 17, 2009 at 10:39 pm
  Lance Walton says:

  Hi again.

  But that is my point. It sounds like you have a particular implementation of Agile Methods in mind, one that would preclude adaptation to the rare situation presented. But that would not be a perfectly run agile project.

  Almost by definition, if the ’standard’ way would get to the result better (for some value of ‘better’) then it would be the duty of the truly agile team to adopt that way, or maybe even find one that increases the betterness.

  The only reasons I can think of for an agile team not adopting a better way are (a) that it is wed to some dogma about what it means to be ‘agile’ instead of focusing on the motivation for agile methods, or (b) that they have perfect knowledge etc., but don’t know that they have it and thus continue to act as if they didn’t.

  Sadly, I’ve seen many examples of (a). With regard to (b), it’s your hypothetical, so you get to decide on whether the agile team is meta-cognitive or not :-)

  Regards,

  Lance
• June 18, 2009 at 2:47 pm
  Jayalal Gopi says:

  “I had the pleasure of speaking with representatives from QSM, Rally Software, VisionOne, innerworkings, NetObjectives, Software Quality Engineering, and VMC among others…” you mentioned about “VisionOne”, Isn’t it VersionOne?
  I use their software for agile project management…
• June 18, 2009 at 3:31 pm
  George Brooke says:

  Look,
  in a perfect world (big assumption), and you have a project which is well understood and with a team competent to implement it, and with a perfectly clear customer, then Waterfall will be cheaper than Agile!
  Please let me know when these circumstances occur so that I can bid on the work.
  Seriously, this hypothetical case does nothing for the discussion. Agile (meaning non-waterfall) will deliver in the real world. Waterfall is the virtual world
• June 18, 2009 at 3:50 pm
  Brad Egeland says:

  Jayalal – You are correct…I was typing too fast I guess. I got it right in my summary of the Expo though, thankfully. I’ve fixed it now in this article. Thanks for the correction!
• June 18, 2009 at 5:08 pm
  Brad Egeland says:

  George- I never knew Agile proponents were so strong-willed.

  Look – I’ve never worked at an organization that uses Agile in development and project management practices. I agree that from what I know about Agile and iterative development practices that it is likely the best solution to use across a project portfolio and will over time yield the highest percentage of successfully, on time and on budget project results.

  As you are fully aware, I was merely presenting a scenario whereas everything being equal and requirements were solidly enough defined at the beginning of the project and the customer is involved and everything goes smoothly, then would the final costs of the engagement actually be lower with Waterfall…or what I was calling ’standard’. I still believe this is true and most everyone has agreed with that assumption.

  And it DOES happen that a dev project run the standard or waterfall way is implemented successfully and provides what the customer wanted and is deployed on time and on budget. I know it can be done because I’ve done it with very happy results. It’s not always easy, and it does require focus, a skilled team, and a very involved customer who was prepared for the engagement at the beginning with good requirements and mapped out business processes. But it does happen.

  That said, I would agree that project success is more likely with Agile and that a higher percentage of projects will likely be on time and on budget with Agile vs. Waterfall. I hope this clears up my view on the matter.
• June 18, 2009 at 8:21 pm
  Agile vs. Waterfall - More Thoughts | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] have to do a follow-up to my article “Agile Software Development Project vs. Standard Software Development Project.”  It was only posted a week ago and has already generated 20 comments.  And many have been [...]
• June 18, 2009 at 9:54 pm
  George Brooke says:

  Brad,
  I think there are misunderstandings here. I am not an “Agile Proponent”. I am a proponent of selecting the methodology which best fits the task / staff/environment (etc). It is not a black and white choice.
  Pure waterfall has no feedback loops. No one uses pure waterfall. Waterfall with feedback is perfectly OK for certain projects, not so OK for others. However, when you see that methods which fit under the Agile heading are in the main extracted from best practices under waterfall then you can see that you can pretty well cherry pick your method to suit your project.
  Personally, probably reflecting pure cowardice on my part, I would always go for iterations. How long for an iteration? My choice, based on risk assessment and motivational issues, not a religious topic. How much requirement analysis is wanted.. well it depends. I was a compiler writer and believe me, there was a lot of up-front analysis. That kind of problem needs it. We still built iteratively though. Same story for OS development. But if you have a project where you cannot perform precise up front analysis then you need an evolutionary approach. have a look at the papers by Tom Gilb on this topic. The key and core benefit of the Agile approach appears to be the iterative/incremental part (re Scott Ambler on this).
  Assuming that we define Agile to mean non-Waterfall, I guess the next question is “What is waterfall?” Say you insert an iteration .. is it still Waterfall? Say you implement continuous integration.. does that stop it being waterfall?
  I have never worked in organisations where dogma could override commonsense but I do come across companies where literal interpretations of methodologies have done just that.
  There is a very nice paper presenting a good discussion of all of this “Improving Software Economics – the top 10 principles of Achieving Agility at Scale”. This is from IBM/ Rational, authored by Walker Royce, the son of Winston Royce who wrote the original, much misquoted paper, on Waterfall techniques applied to software production many years ago. Winston did nto actually propose the single-pass waterfall approach which was generally adopted. We seem to be full circle now.. but I strongly recommend the paper as a good clarification of the essentials, without the dogma of the Agilists.
• June 19, 2009 at 1:54 pm
  ????? ?????? ????? ????? » Blog Archive » Agile Development Versus Traditional Development says:

  [...] Egleland has a post titled Agile Software Development Project vs. Standard Software Development Project where he conjectures there is less cost, lower rework, and the final product is closer to the [...]
• June 23, 2009 at 4:26 pm
  Alex Smirnoff says:

  I think that I am about to echo multiple earlier posts. I do believe that the dilemma that started this discussion is a purely theoretical construct. A choice of methodology should be defined by a nature of the project. Projects best suited for the Agile development is probably are not even doable using Waterfall, project well suited for Waterfall are not well suited for Agile. If you have a stable requirements set at the very beginning, why on earth you incur all the Agile overhead aimed at prioritizing functionality. I have to say though that I do not think that we have any programs left that are well suited for Waterfall. I think that model (that I, btw, do like) is on its way to retirement. With the requirement flux we currently see across the industry, Waterfall is simply not a viable option. At the same time, I have never seen agile working for a large scale program that has hundreds of requirements and few hundred SW developers. I think that we, as an industry are in the bind at the moment. Our well established methodologies are not working that well and our new methodologies are not well instantiated yet. This is way we have so many “red” programs at the moment.
• June 23, 2009 at 4:52 pm
  George Brooke says:

  Alex,
  I am sorry that I got involved with this discussion. However, I accept your points. Some people forget that there is a massive range of project types out there. They are not all Web apps, neither are they all weather-forecasting or chess playing apps. We need to be able to cherry-pick from an approved set of best practices, preserving standard terminology and management organisation, thus benefiting from standardisation. Coming from compiler development and the like, I am quite used to iterative and incremental development, 24 by 7 continuous builds and test-automation and so on, and all of this was under a so-called waterfall environment. Remembering that Agile was supposed to be a distillation of best-practices from earlier time, there is nothing to stop us retrofitting them back into poor waterfall implementations, if that si want it takes to move things on. I don’t see a waterfall and agile world.. I see a continuum of selectable techniques. See http://www.eclipse.org/epf/general/description.php
• June 24, 2009 at 5:06 pm
  Ashley Morris says:

  Brad – great article, as I was just talking with our CEO about this the other day. We think that in an ideal world, where developers can literally build exactly what’s in the requirements doc in a standard process, that it could actually be cheaper than Agile.

  However, we’ve never had a client who knows exactly what they need up front. We’ve never had a client that hasn’t changed their mind. We’ve never had a client that had exactly what they wanted at the end of a standard development process, which is why we no longer use it.

  If it’s widely known that requirements change and thinking evolves during development, why fight it? Why not adopt a methodology that embraces change and lowers risk for everyone? The client may end up paying slightly more for the product, but get this — they get a product they can actually use in the end.

  That’s infinitely more valuable than saving a few dollars and ending up with a useless system.
• June 26, 2009 at 3:33 am
  How to Ensure Project Success Every Time | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] is no such thing. We all know that. The recent discussions on Agile vs. Waterfall on here (see “Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”) might make you think differently based on [...]
• June 28, 2009 at 2:26 pm
  Dave says:

  Several things:
  a) Perfect requirements and no change of mind in a 6 month project are unheard of, in a 12 month one I think are a fiction beyond the pale.
  b) I have yet to meet a scrum team that isn’t less than 25% quicker at any given project or task than a waterfall team, and in general its around 4 or 500% quicker – yes 4 or 5 times the speed (in code, function points, reduced budget, measure how you will).

  The improved ’speed’ is from a combination of improved team communication (daily meets are invaluable) and much improved morale (things have been delivered), more focus (next delivery next week), lack of prolonged test and fix cycle (common for all iterative methods there is a test and fix for each short burst of development, this reduces the long and painful test and fix at the end), reduced time between monumental ‘cock up’ and spotting it – due again to the test and fix in each cycle.

  One day someone may prove me wrong and show me a standard or waterfall project that was cheaper than the scrum equivalent, I have yet to see it.
• June 28, 2009 at 8:07 pm
  Agile Software Development in a Standard Project Management Methodology | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] software development process discussion that is still going on based on two other articles (“Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More [...]
• July 7, 2009 at 4:05 pm
  Gustavo R says:

  I think the “agile” school evolved from the Barry Boehm concept of spiral development. This methodology is a reaction to the fact that traditional waterfall didn’t do well with risk management (remember the Standish Group statistics about failure software projects), particularly the risk of having instable and not well defined requirements.

  Based on the spiral concept, some people like the guys that founded Rational (Grady Booch, Ivar Jacobson and James Rumbaugh) adapted the concept to traditional Waterfall and then the iterations born. The concept evolves into Agile methodologies, I believe that the first one was Alistair Cockburn, this concept was also impulse by the increasing popularity of 4GL and OAAD, which allows to create prototypes easy and faster.

  My final thought is that after all this time, there is almost not traditional waterfall any more and more and less everyone has incorporated some kind of strategy to manage requirement risks in projects such as: prototyping, shorter development cycles, re-usable objects, SOA, etc.
• July 9, 2009 at 2:11 pm
  Pett says:

  Super post, Need to mark it on Digg
  Pett
• July 18, 2009 at 10:43 am
  AnnaHopn says:

  Hi there,
  Everything dynamic and very positively! :)
  Thanks
  AnnaHopn
• July 24, 2009 at 7:18 pm
  Eremeeff says:

  Amazing! Not clear for me, how offen you updating your pmtips.net.
  Thanks
• July 25, 2009 at 4:26 am
  Brad Egeland says:

  Pett- Thanks for commenting…this article was fun and educating for me to write and very interesting to see the high volume of feedback comments it has received.
• July 25, 2009 at 4:26 am
  Brad Egeland says:

  Anna- Thanks for the comment – I always appreciate the feedback!
• July 25, 2009 at 4:28 am
  Brad Egeland says:

  Eremeef- Thanks for reading and thanks for the comment. We try to post about 40-50 articles per month on this site…I usually post 25-30 per month. And as always, I rely on your feedback for ideas and motivation. Thanks again!
• July 28, 2009 at 2:38 pm
  Pett says:

  Where are you from? Is it a secret? :)
  Thank you
  Pett
• July 28, 2009 at 3:13 pm
  George Brooke says:

  Hi,

  Scott Ambler provides some useful survey feedback on the actual use of Agile techniques. I quote from Scott:

  “To give you a feel for the results of the survey, some of the findings (which I’ll expand upon in August) include:
  1. The three practices which are seen as most effective were Continuous Integration (CI), Daily Stand Up Meetings, and Developer Test-Driven Development (TDD).
  2. The three practices which are seen as easiest to learn are Daily Stand Up Meeting, Continuous Integration (CI), and Iteration Planning.
  3. The three practices which are seen as hardest to learn are Developer TDD, Acceptance/Story TDD, and Pair Programming.
  4. The three practices which were most likely to be tried and then abandoned were Pair Programming, Burndown Tracking, and Potentially Shippable Software Each Iteration.
  5. The three practices which people want to adopt but have not yet done so were Acceptance TDD, Potentially Shippable Software Each Iteration, and Developer TDD. ”

  I am certainly interested in the full survey but as you can see from (1) it is pretty conventional and in fact these techniques are well known and can be used in projects with any level of formality. I think the real world should mix and match techniques according to project-type. All that “Agile” really means at core is that it is at least “non-sequential”, if Waterfall is assumed to be sequential. As it never really was anyway, and certainly was not intended to be if you look at the history, I think we have been suckered into this discussion and this definitely my last contribution on the subject, in this iteration.
• July 28, 2009 at 7:42 pm
  Brad Egeland says:

  Pett – LOL…it’s no secret….but if it makes me seem more mysterious to the readers then maybe I shouldn’t tell. Seriously though…I’m from Iowa originally and I was there until early 2004, when I moved my family out to Las Vegas, NV. We’ve been here now for about 5 1/2 years. Very different local from eastern Iowa…but the weather is great. I do not miss all the rain, snow and humidity.
• July 28, 2009 at 7:45 pm
  Brad Egeland says:

  George – thanks for the comment and the reference to the survey. Very interesting information. Can you provide a link to the full survey info? Thanks.
• August 8, 2009 at 3:45 pm
  SonyaSunny says:

  Hello,
  I have already seen it somethere…
• August 8, 2009 at 4:15 pm
  Brad Egeland says:

  Sonya- I’m not certain of what you are saying… thanks for stopping by and commenting. You can provide more comments here or email me at brad@bradegeland.com. Thanks.
• August 24, 2009 at 7:49 pm
  Elcoj says:

  Hello,
  Interesting, I`ll quote it on my site later.
  Have a nice day
• September 15, 2009 at 10:12 pm
  Bodyc says:

  Hi, pmtips.net to GoogleReader!
  Have a nice day
  Bodyc
• September 21, 2009 at 6:13 am
  Saurooon says:

  Greatings, Interesting, I`ll quote it on my site later.
  Saurooon
• September 27, 2009 at 8:25 am
  Elcorin says:

  Not sure that this is true:), but thanks for a post.
  Elcorin
• October 1, 2009 at 3:57 am
  Brad Egeland says:

  Sauroon-

  Thanks for reading and commenting. I look forward to your quote!
• October 1, 2009 at 3:58 am
  Brad Egeland says:

  Bodyc-

  Thanks for commenting…your readership and opinions are greatly appreciated!
• October 1, 2009 at 3:59 am
  Brad Egeland says:

  Elcorin-

  Whether you agree or disagree, I always want to hear everyone’s opinion. Thanks for reading and commenting!
• October 26, 2009 at 2:00 pm
  Robor says:

  Can i get a one small photo from your site?
  Robor

Search for:




Share your opinion
Share you project management knowledge and expertise with the hundreds of thousands readers of PMTips.net. Let your voice be heard! Apply here!
Who's Talking
Popular Posts
Popular Posts
• How to Make Your PMO More Visible
• Social network for Project managers - PPMNG
• Project Management: Is PMP Certification Worth It?
• The Project Kickoff
• Agile Software Development Project vs. Standard Software Development Project
Recent Comments
Recent Comments
• Bruno Spinelli on Agile vs. Waterfall – More Thoughts
• uberVU - social comments on Is Project Cancellation Always Bad?
• uberVU - social comments on Project Communication Series: PM Communication Skills
• Carron Baths on Common Project Issues: Underestimating Complexity
• Dana on Project Communication Series: The Project Status Report
We Recommend
• Seavus DropMind™
• Seavus Group
• Seavus Project Planner
• Seavus Project Viewer
Categories
• Project Management
  • Tips
  • News
  • Tools
  • Opinion
• Knowledge Management
  • Tips
  • News
  • Tools
  • Opinion
• Collaboration
  • Tips
  • News
  • Tools
  • Opinion
Resources
• Gantthead
• ICPM
• Mind Tools
• PM Toolbox
• PPMNG
• Project Smart
• Reforming Project Management
• The Lazy Project Manager
Subscribe for e-mail