<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Managing innovative projects: Don't mistake the map for the journey ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-310080/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-06-19T09:07:16-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[I Hate Agile]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3097787]]></link>
        <description><![CDATA[What do you get when you have no stucture (besides a lot of blamestorming and fingerpointing?) Why, Agile!Agile is a political doctrine, not just an approach, which makes it especially creepy. They even have a manifesto. So, putting it in place is like asking people who are monogamous to accept polygamy as an acceptable practice. I believe the only thing Agile has going for it is that you cannot actually pinpoint failure. As my management team would probably say, &quot;well... when is failed really failed?&quot; This approach is like its own entity that builds steam and moves and shapes its own way, plowing over management, disregarding show stopping issues, user feedback, user's begging you not to roll out....You know what it really is with that marketing term removed? It?s a pack mentality. This &quot;approach&quot; has spawned nothing but downwad pressure, denial, lies, deceit, and resentment due to heinous time constraints and rampant politics caused by lack of structre -- and no one even knows where the pressures are coming from anymore! Furthermore, no one questions it! People just lie and cover up. We have been working working 12-14 hours days for the past year iteration after freaking iteration and are now training on a system that is 20% complete, lying to users, with developers who are covering up bugs and errors and making it impossible for us to find errors. People will wake up from this and this horrid fad will be exposed. Agile sickens me.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3097787]]></guid>
        <dc:creator><![CDATA[misdelivery]]></dc:creator>
        <pubDate>Wed, 17 Jun 2009 19:45:48 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[A good PM is part politician........]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3092258]]></link>
        <description><![CDATA[I agree that certification is important. But not all is learned from a book. Good people skills, the ability to interface upward with management, horizontally with your peers and below to your support staff is a process developed with experience. PM's develop this skill at varying rates. But the only way a newly certified PM will have this, is via experience.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3092258]]></guid>
        <dc:creator><![CDATA[adam_dipasquale@...]]></dc:creator>
        <pubDate>Wed, 10 Jun 2009 10:31:05 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[By definition: Project = The future is what you make]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3090523]]></link>
        <description><![CDATA[For all you Terminator fans I think that's close and it pretty much defines &quot;Project&quot; in the real world.When a manufacturer of widgets is making their 1 millionth widgets that's not a project. When they want to make a new gizmo that's a project. While their knowledge of widget making lends more predictive credence than if they had just emerged from a cave it in no way is a guarantee of success, schedule, or budget.That is why most projects, agile or not, first start of with a course estimate which is refined as it goes on. Those entities that demand Big Requirements Up Front before loosening the pursestrings can pretty much be sure of revisiting the well.We need look no further than the plethora of project management strategies that abound to know this is true; we wouldn't have so many if any of them worked.This is not to say that there is no value but rather that project management is knowledge based as well as inventive and flexible. PMI has it right in basing certification on experience (the rest of it is just the ability to take a test) which is the best indicator of having a large toolkit to deal with the unexpected; pretty much the one thing you can count on in any project.There are many other aspects of project management that could be discussed but mostly it's Stanley's search for Livingstone where the end result is what is important.As a side note it's interesting that movie making was chosen as an example. It's one of the few things I can think of that has a firm deadline; opening day is opening day. That Peter Jackson could deliver the Lord Of The Rings (sorry for being a geek) on time when there was nothing in his background that suggested that he could pull it off is remarkable. The budget and planning process would probably make a good case study.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3090523]]></guid>
        <dc:creator><![CDATA[fidlrjiffy@...]]></dc:creator>
        <pubDate>Mon, 08 Jun 2009 07:49:00 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[The script, the script]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3088066]]></link>
        <description><![CDATA[A lot of the govt depts in my state use Prince2 as the methodology of choice. I see project plans with references to page numbers, change is managed via the issues log, see page 272 of your Prince2 Manual. Painting by numbers, whilst we all know project management is a lot more about the deadly combo of brains and brawn.Like you, I'd assign a confidence level to different stages of my initial project plan, with some order of magnitude depending on the stage we are in when I revise the estimates. Shared risk. How can one estimate how long a legal review takes when one considers a cloud solution? Time boxing assists with mitigating these issues.I also see a lot of project managers who build impressive schedules and documents but can't drive the ball home. What needs to be done first? Quicky Iterations and incrementations also help with chipping down the political barriers. And so on and so forth.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3088066]]></guid>
        <dc:creator><![CDATA[biancaluna]]></dc:creator>
        <pubDate>Thu, 04 Jun 2009 03:25:54 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Managing innovative projects: what the business wants?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087567]]></link>
        <description><![CDATA[Yes, a great phrase, reminds me of what Napoleon said, &quot;A plan is only good until the battle is joined.&quot;But one thing: &quot;...it is the observable truth that, especially in innovative programs, customers can?t describe what they want until they see it, ...&quot;.The key word is &quot;want&quot;; nobody can tell you everything they want, it is too open-ended a question. Instead, effective requirements elicitation techniques can be used to define what the customer actually needs.If you truly have a new business program or product, something the organization has not done before, so there are no subject matter experts, then you really can't elicit requirements; prototyping and such is the way to go.However, too many projects assume the above is true when it isn't. For a new business effort with a software component that is within the experience/knowledge of the organization, such that SMEs are available, you can get what that project needs defined before any developer joins the project.How? Don't ask people what they want, ask them what they do. Business people can tell you that, so get them to describe it to a low enough level of detail such that you can extract Functional and Informational Requirements.David Wrighttwitter.com/dwwright99www.iag.biz]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087567]]></guid>
        <dc:creator><![CDATA[dwwright99@...]]></dc:creator>
        <pubDate>Wed, 03 Jun 2009 10:28:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[No Bureaucracy Here]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087368]]></link>
        <description><![CDATA[Certification does not ensure a project bureaucrat.  If all you did is remember facts then maybe that all you know, but decent PM's know what they need and what the don't.  I don't know any good people who want to make extra work for themself just for the sake of bureaucracy.  You must have PM's consufed with government politicians.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087368]]></guid>
        <dc:creator><![CDATA[mpyea@...]]></dc:creator>
        <pubDate>Wed, 03 Jun 2009 07:24:59 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Innovative software projects are not ditch digging]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087334]]></link>
        <description><![CDATA[AAAAAMEN BROTHER!I always make a mental measurement about the management I'm dealing with when they expect definition and design to be estimated work.  It's not ditch digging fellas. It's TIMEBOXED work, and that's not the same thing.We're going to timebox requirements &amp; design at X weeks. At some point prior to the end of that, we're going to take a reading to see if we're going to be done enough to proceed by the end of the timebox. If not, look for a change notice from me.And when I do give you that estimate of the dev work, it's going to come as a range, not a precise number out 4 decimal places. It's also going to come with some clarifying info like the confidence level behind the numbers so you can share our security or uncertainty about the whole deal. That confidence level is going to tie directly to the +/- variation I'll include as risk reserve in the range I gave you.Most project bureaucrats don't really &quot;get&quot; project management to start with and want everything to work like the recipe for jello. They get very consternated when real life doesn't work out so neatly, and can't project manage their way out of a paper bag because there's no script to follow.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087334]]></guid>
        <dc:creator><![CDATA[PunkRock_PM]]></dc:creator>
        <pubDate>Wed, 03 Jun 2009 07:00:12 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Managing managers]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087292]]></link>
        <description><![CDATA[I like the article but the profession of project management is still hopeless. If a VP wants a good PM, he either chooses one who has already been successful or he hires someone who is certified in project management. Getting the certification ensures training in becoming a project bureaucrat.The bad approach rolls down the line. The VP wants to manage his process so he looks for paperwork to prove you are a good project manager. And all the folks who trained you expected you to produce paperwork.Bad management and stupid processes, like sewage, always finds a way to flow downhill.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3087292]]></guid>
        <dc:creator><![CDATA[minstrelmike@...]]></dc:creator>
        <pubDate>Wed, 03 Jun 2009 06:31:44 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Please ... no .. no]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3086835]]></link>
        <description><![CDATA[Please don't force me to defend Agile. Please no .... oohh my head is going to explode ... must not give in ... boom! ]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3086835]]></guid>
        <dc:creator><![CDATA[PMPsicle]]></dc:creator>
        <pubDate>Tue, 02 Jun 2009 14:09:47 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[You hit the nail dead on]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084635]]></link>
        <description><![CDATA[Great piece. Nailed it. I have done both sides ,developer and coding, and find that successful developemnt and release is like running a war game with things, even the goal, changing all the time -at least for new initiatives (maintenance is another story). Yes we had a plan, but found that if we all understood that the plan could change and that that was part of the plan, then everybody was much calmed because there were no unmet expectations. ie going in knowing that is was going to be &quot;agile&quot; and that the management writing the checks knew that agility could mean more $$$ or more time, and also knowing that they know that even they (management) at some point had to make a decision and stick with it, seemed to calm everything down.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084635]]></guid>
        <dc:creator><![CDATA[jamjube]]></dc:creator>
        <pubDate>Fri, 29 May 2009 08:17:05 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Managing innovative projects: Don't mistake the map for the journey]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084568]]></link>
        <description><![CDATA[Good article.In the years I've been PM'ing this is a phrase I have found myself using to explain the concepts while discussing the beast with a client.&quot;There is what you want...&quot;&quot;There is what you plan for..&quot;&quot;There is what you implement..&quot;&quot;There is what you get..&quot;&quot;None are related to the other..&quot;&quot;Be flexible and patient, it's not a matter of if, but when..&quot;Usually works as most stakeholders could care less about the techno-babble and are looking for a simple explanation to help them rationalize their decision.The secret of course, already alluded to by previous posts is &quot;slaying the dragons&quot; without derailing the project (ala. creep).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084568]]></guid>
        <dc:creator><![CDATA[miles999@...]]></dc:creator>
        <pubDate>Fri, 29 May 2009 07:09:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Agile = b@##-s%*t marketing term]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084336]]></link>
        <description><![CDATA[Liked the article and your response Glen.  &quot;The good PM knows which to apply and when&quot;, hence why I will continue to argue that agile is just a b%*ll-s%$t marketing term and good PM's who have been around for a while know what to apply when - its how we are successful and its how we get our projects done.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3084336]]></guid>
        <dc:creator><![CDATA[chris@...]]></dc:creator>
        <pubDate>Fri, 29 May 2009 01:49:19 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[That's My Experience too]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083967]]></link>
        <description><![CDATA[Yeah - this and your other post probably hit the nail. They same to be two sides of the same coin. Either you know the scope of what your going to deliver but not when you can deliver it - or you know when you can deliver something but not what that something is. A sort of Heisenberg's Uncertainty Principle for Developers.Hence PM's always need to get good at politics - because there is no certainty.And once you realise that Brooks law holds (ie: that adding more man power to a late project makes it later) - you realised quite how screwed you are!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083967]]></guid>
        <dc:creator><![CDATA[Danny Graham]]></dc:creator>
        <pubDate>Thu, 28 May 2009 10:49:47 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Actually ...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083899]]></link>
        <description><![CDATA[Actually, it is easy to quote a timescale with agile.What isn't easy is saying you'll actually produce anything useful in that timescale.That's the basic difference between Agile and Waterfall. Agile is time bound -- what can you finish in this amount of time? Waterfall is scope bound -- how long will it take you to do this?Glen Ford, PMPhttp://www.trainingnow.ca]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083899]]></guid>
        <dc:creator><![CDATA[PMPsicle]]></dc:creator>
        <pubDate>Thu, 28 May 2009 09:02:32 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[A different response for me ...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083898]]></link>
        <description><![CDATA[Normally, I get to try to reign in the pro-Agile/anti-Waterfallers. I'm not going to this time (Wow, H**l must have frozen over!  )Instead, I get to point out 3 really great pieces in this article. First, is the phrase in the title &quot;don't mistake the map for the journey&quot;. Bloody excellent! Far too many managers (project and sponsor) forget that the project plan is a guess. It's an estimate of where the project is going to go. A map created by a blind cartographer based on hearsay. The mark of a good PM is not the ability to follow the map. Nor even to make the map. It's the ability to survive when the dragons are stumbled on. The great PM can run into a dragon and have no one realize it. PMs play the variance game ... sometimes they win, sometimes they lose. Beware of the dragon, for you are crunchy on the outside and chewey on the inside.Hope you don't mind but I'm going to steal that phrase to use on some of my sponsors &amp; company leadership. Along the same line are the two types of PM; the project manager and the project bureaucrat. There is a reason that the PMBOK is a framework not a methodology. And why any good methodology has a step to modify itself before being used. Following any methodology blindly only shows that you don't understand it enough to adjust it to the situation. Finally, in the article you state &quot;Agile approaches are appropriate for creative, inventive projects&quot;. Someone who finally gets it!  Agile does have its place. Structured/Waterfall also has its place. Use the either one in the wrong place and you are fighting yourself. The good PM knows which to apply and when. That's why we're not operational managers. We're supposed to be flexible!Glen Ford, PMPhttp://www.trainingnow.ca]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083898]]></guid>
        <dc:creator><![CDATA[PMPsicle]]></dc:creator>
        <pubDate>Thu, 28 May 2009 08:57:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[True - but how do you quote a timescale?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083843]]></link>
        <description><![CDATA[It often strikes me that techniques such as Agile through its use of a rapid protyping strategy is very in tune with how developers think and can organically grow a solution. Essentially mixing planning with research and development.The problem is that particularly with very inventive ground breaking new projects, Management want timescales as to when the solution will be delivered, often many months ahead. Developers often perceive this as unreasonable - but managers do have a genuine need for reliable estimates. For example they may have to schedule trade shows or arrange user group conferences around the new project which often for practical reasons (say securing a large enough venue) have to be done a long time in advance.So given the iterative nature of agile and the way that each new calculated timescale is only a successive approximation to the truth - how can you quote a timescale up front - that you can rely on and that will allow the rest of your business to coordinate its activities with you?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-310080-3083843]]></guid>
        <dc:creator><![CDATA[Danny Graham]]></dc:creator>
        <pubDate>Thu, 28 May 2009 08:01:22 -0700</pubDate>
    </item>
    </channel>
</rss>

