• Explore More Strategy Topics

  Agile Agility Alignment Architecture Benchmark Business Cost Decision-Making Definition EA Enterprise Architecture Enterprise Archuitecture Execution Framework Good Enough Governance GTD Heuristic IEEE 1457 IT IT Governance ITIL Management Measurement Methodology Performance Planning Planninig Principle Principles Process Project Reference Architecture Research Security Simple Small Wins SOA Social Architecture Software Architecture Solution Standards Strategy Technology Thinking TOGAF Trends Zachman

• Blogroll

  • Enterprise Architecture: From Incite comes Insight…
  • Pragmatic Enterprise Architecture
  • Serge Thorn’s IT Blog
  • Smart (Enough) Systems
  • Technology Architecture & Projects
  • The Practice of Leadership
  • Todd Biske: Outside the Box
  • User-Centric Enterprise Architecture

Michael Hugos has a great post on agility where he makes the following point:

“Experience shows me (again and again) that agility is not about working fast but about finding elegantly simple solutions to business problems. You’ll know you’ve found an elegantly simple solution when the business people agree it solves their most important and immediate problems and when the developers know the solution can be built and tested in 30 days or less.

Unless you find a solution that meets these two criteria, it’s not possible to be agile. And often, because people can’t find these simple solutions, they mistakenly claim that agility itself doesn’t work. They come to this conclusion because they attempt to be agile by cramming complex solutions into short development cycles through working harder, longer, and faster.

That attempt has as much chance of success as trying to cram ten pounds of you-know-what into a five pound bag. Inevitably, the bag breaks, and then there is a mess to clean up.

An elegantly simple solution (a robust 80% solution) doesn’t do everything (there isn’t time for that), just the most important things. Finding this solution is not easy; it’s the creative part. It requires business people to figure out what tasks out of all the tasks they perform are the most important ones and what system features they need to handle those tasks. Then developers have to figure out how to build and test a system to deliver those features in the short amount of time available.”

We spend too much time complicating our lives by trying to do too much, too fast! There seems to never be enough time to do something correctly, but always enough time to do it over again! Given to complexity of managing technology, we’re prone to think that complex solutions, are better solutions. Instead we need to focus on implementing good enough solutions, solution that bring about small wins. Small wins, if continually applied, in a thoughtful and strategic manner, quickly add up to significant results. Small wins are more manageable and have less of an impact if they fail. Seeking big wins are extremely difficult, prone to failure and require significant political will! Focus on the small wins…. simple things done well!

Technorati Tags: Agile, Agility, Simple, Small Wins, GTD, IT, Project, Management, Business, Technology, Architecture, Good Enough, Execution

Stephanie Overby CIO.com presents her view of the Anatomy of an IT Strategic Plan as follows:

• Timing: Most IT leaders will want to start thinking about the IT strategic plan in the spring to best position themselves for the budgeting cycle. An IT organization’s first strategic plan can take anywhere from three months to a year to write.
• Time Frame: The plan should cover three to five years, with the most focus on the next 12 to 18 months unless there is a longer-term project on the table.
• Medium: Word document and/or PowerPoint presentation. Create an abbreviated version that you can turn to anytime someone has an issue or question.
• Length: 15 pages. Or less. If using PowerPoint, 25 slides. Or fewer.
• Executive Summary: The plan should begin with a summary targeted for the business audience.
• Scope: High-level goals and plans for all areas of information technology that affect the business, not just the infrastructure. A road map for IT is useful in illustrating overall strategy.
• Business Context: Lay out the specific business drivers, assumptions and plans that informed the IT strategic plan. (For example, the business is planning to acquire smaller companies so IT’s plan is to focus on integration technologies.)
• IT Principles: Short statements of purpose that will guide IT decision making and implementation.
• Metrics: Put measurements of progress in place when you create the strategic plan instead of waiting for review time to figure it all out. The goal is not precision but the ability to measure appropriate progress toward goals.
• Review: You should review the plan and revise it as necessary at least once during the fiscal year.

This is a great checklist for your IT strategy…

Technorati Tags: Strategy, Plan, Planning, IT Strategy, Goals, Objectives, Management

• Search for:

• Welcome

  Welcome to Architecture and Change. You can subscribe to my blog using RSS or you can subscribe by e-mail

• Contact

  
  
  

• Busy Reading...

• Interesting Blog Stats

• Show of Support