<story><title>Understand, Design, Build: A Framework for Problem-Solving</title><url>https://lob.com/blog/understand-design-build-a-framework-for-problem-solving</url></story><parent_chain></parent_chain><comment><author>thinkingkong</author><text>Reminds me of this incredible chart &amp;#x2F; graph which you can use to apply to a lot of situations. I actively refer to this and show it to teams constantly. The gist of it is that you require many skills and capabilities to create alignment. Without that, you have different outcomes which we may initially experience as frustration &amp;#x2F; failure.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;intenseminimalism.com&amp;#x2F;2015&amp;#x2F;a-framework-for-thinking-about-systems-change&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;intenseminimalism.com&amp;#x2F;2015&amp;#x2F;a-framework-for-thinking-...&lt;/a&gt;</text></comment>
<story><title>Understand, Design, Build: A Framework for Problem-Solving</title><url>https://lob.com/blog/understand-design-build-a-framework-for-problem-solving</url></story><parent_chain></parent_chain><comment><author>Spearchucker</author><text>This framework is good. And like the other frameworks in other comments here, it&amp;#x27;s a good enough start in a small company, start up, or small department within a larger organisation.&lt;p&gt;A better framework might be cobbled together from various disciplines. For instance, &amp;quot;Understand&amp;quot;. This part is huge. Well, bigger than those three questions the author lists.&lt;p&gt;&amp;quot;Understanding&amp;quot; begins by stepping back to look at the environment as a whole. Bound the situation. Assess organisational culture, the environment (immutable aspects of a transformation&amp;#x2F;process), the organisation&amp;#x27;s technology landscape (Active Directory?), regulatory requirements, competition, suppliers and customers.&lt;p&gt;There&amp;#x27;s also the social system (roles, norms, values), and the political landscape.&lt;p&gt;Then you define your objective. But before you can do that you need to know who your client is. Sure, in SV that&amp;#x27;s often easy. Outside that bubble not so much. Identify the client by asking some questions - whom do you need to satisfy? Who will judge the success of the project? Who will fail if the project fails? Who has authority for the project? Who pays for the project? Whom do you report to?&lt;p&gt;After all that you&amp;#x27;re ready to set an objective. Vision&amp;#x2F;scope stuff. Specific, measurable, attainable, realistic and time-boxed. Cliche&amp;#x27;d, but when a project goes wrong the specification is the only version of the truth a team has to fall back on.&lt;p&gt;Setting project objectives is much bigger than I can do justice to here. However once you have that you can start with the fun stuff. Design, build, deploy, repeat until done.&lt;p&gt;However while you&amp;#x27;re doing the fun stuff you still have to do the unfun stuff too - risk management, and stakeholder management. And it&amp;#x27;s stupefyingly incredible how many people think they know how to do these things but can&amp;#x27;t readily explain the difference between mitigation and contingency, exposure and impact, or why you have to be nice to the CIO for your project to succeed, even though the CTO and CEO are on your side.&lt;p&gt;I&amp;#x27;ve written about all this stuff. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.wittenburg.co.uk&amp;#x2F;Entry.aspx?id=8ec91ced-b3a4-4b07-bf91-17f0efda1718&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.wittenburg.co.uk&amp;#x2F;Entry.aspx?id=8ec91ced-b3a4-4b0...&lt;/a&gt;</text></comment>