{"id":181,"date":"2010-09-19T15:12:49","date_gmt":"2010-09-19T22:12:49","guid":{"rendered":"https:\/\/analogman.org\/?p=181"},"modified":"2010-09-20T15:51:03","modified_gmt":"2010-09-20T22:51:03","slug":"perhaps-we-are-asking-the-wrong-questions-agent-brown","status":"publish","type":"post","link":"https:\/\/www.analogman.org\/?p=181","title":{"rendered":"Perhaps we are asking the wrong questions  &#8211;  Agent Brown"},"content":{"rendered":"<p style=\"text-align: center;\"><strong>7 \u00bd step path to a successful project<\/strong><\/p>\n<p style=\"text-align: left;\">\n<p>There aren\u2019t really seven and one half steps to magically manage successful projects, or ten for that matter, but there are a number of items that will always require careful and diligent attention.<\/p>\n<p>I was working on a project writing a database query interface for a law firm a number of years ago (more years than I would like to specify &#8211; when dBase III was king) and during a discussion of the project with a seasoned programmer friend of mine I said, \u201cWhen I finish coding this I am going to compile it and never touch it again.\u201d My friend laughed.<\/p>\n<p>For a long time.<\/p>\n<p>At that particular moment I didn\u2019t see the joke but after the stakeholders redefined the functionality of the project time after time without any seeming willingness to alter either the timeline or cost allowances I came to see the very deep dark humor in my statement. On so many levels.<\/p>\n<blockquote><p>\nField Marshall Helmuth Carl Bernard von Moltke said once upon a time in the late 19th century, \u201cNo battle plan ever survives contact with the enemy.\u201d\u00a0 Dwight Eisenhower followed up a few years later with, \u201cIn preparing for battle I have always found that plans are useless, but planning is indispensable.\u201d\u00a0 I am now convinced they were both seasoned project managers who believed deeply in the need to plan but they also had the benefit of vast experience allowing them to embrace the fact that a plan is just a way to get started doing something.\n<\/p><\/blockquote>\n<p>The sad truth is I like plans, especially when they help guide me through complex tasks. The caveat is simply that the plans I make are completely ignored by life, requiring that they be constantly updated (read changed) during any meaningful project. In creative, new projects, this process of change has to be an iterative process. I always try to remember that, like a marriage, flexibility within the agreed upon framework is primary. Evolution is life, life is change, impermanence just is. The plan will change, be open to that. Hell, plan for it.<\/p>\n<p>P.S.\u00a0 The scope of this article does not include arguing about PMP vs. Prince2<\/p>\n<p style=\"text-align: center;\"><strong>The 7.5 fold path to enlightenment.<\/strong><\/p>\n<p>1. What is the goal? Notice I didn\u2019t say \u2018your\u2019 goal because a project\u2019s goal belongs to the stakeholders, you are the catalyst in a complex chemistry project. A big part of your job as the project manager is to help the folks the product is being built for clearly define what the product is. Some people go so far as to say that if you can\u2019t define the goal in a single sentence you\u2019re not likely to ever reach it\u2026<\/p>\n<p>2. Spend some time planning . Self evident yes, but we have a tendency to want to \u2018get going\u2019 on projects. Take the time to deconstruct. Reductionism is good when applied properly. Break down the big picture into smaller absorbable, manageable parts. Include an iterative process of requirements capturing. Gather data, sometimes it will not even seem related to anything meaningful until you have that epiphany next month. Don\u2019t ever assume you know what the end-users need.<\/p>\n<p>3. Hold onto the big picture. Don\u2019t forget that the smaller parts are interconnected pieces of a complex system of parts that must have a common goal. Sometimes the evolving subsystems don\u2019t evolve in the direction you need. Gently guide everyone back on track when they have wandered off into the woods.<\/p>\n<p>4. Communicate. With everyone. All the time.<\/p>\n<p>5. Know your team. Have them all read #4. Support them, lead them, help them communicate with each other and you. Trust them and make sure they can trust you. Maybe they really do like pizza?<\/p>\n<p>6. Know your Stakeholders.\u00a0 Who are they and what is their relationship to you and the project. They will run the gamut from the people that pay the bills through to the people that are using the end result of the project.\u00a0 And\u00a0 since we don\u2019t know everything we may have to reach outside the team to find \u2018experts\u2019 to help in specialized areas like the law or cell phone app design. Listen to all of them carefully. They are the people that are going to decide if you have really completed the project.<\/p>\n<p>7. Test. Test again. Test early, test often. (See #3) Make sure the pieces are fitting together. Evolve the project parts concurrently whenever possible &#8211; hopefully avoiding that day when the two halves of the bridge are coming together and you missed the fact there is no place to put the off-ramp.<\/p>\n<p>7.5 Own your project but don\u2019t let it own you. Embrace change and be flexible but remain focused on the goal.<\/p>\n<blockquote><p>\n\u201cNo battle was ever won according to plan, but no battle was ever won without one.\u201d &#8211; Dwight D. Eisenhower.<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p>7 \u00bd step path to a successful project There aren\u2019t really seven and one half steps to magically manage successful projects, or ten for that matter, but there are a number of items that will always require careful and diligent attention. I was working on a project writing a database query interface for a law [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[3,4,10],"tags":[],"class_list":["post-181","post","type-post","status-publish","format-standard","hentry","category-editorial","category-recent-readings","category-training"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/posts\/181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.analogman.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=181"}],"version-history":[{"count":13,"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/posts\/181\/revisions"}],"predecessor-version":[{"id":193,"href":"https:\/\/www.analogman.org\/index.php?rest_route=\/wp\/v2\/posts\/181\/revisions\/193"}],"wp:attachment":[{"href":"https:\/\/www.analogman.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.analogman.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.analogman.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}