The Art of the Recap

November 7, 2016

If a meeting occurs, but nobody sends a recap, did the meeting happen?

We have blogged about the importance of a meeting recap, but spoke more of the practice of using meeting recaps and less of the art of creating a good recap. We do have internal guidelines that we follow, but through our mentoring process we also attempt to build expertise beyond the template and guidelines. This is my attempt to share some of that company lore. Read more



“Who” Creates Risk

September 15, 2016
Costello: Well then who's on first? Abbott: Yes.
Costello: I mean the fellow's name. Abbott: Who.
Costello: The guy on first. Abbott: Who.
Costello: The first baseman. Abbott: Who.
Costello: The guy playing... Abbott: Who is on first!

Today’s blog is triggered by the entry authored by my friend and colleague, Ben Sommer, reflecting on the laziness of describing architecture with pronouns. In our roles as architects, IT strategists, or just technical leaders guiding successful project implementations we frequently find ourselves defining plans and parceling out tasks.

Read more



Avoiding a Leaky Scope Bucket

July 1, 2014

There’s a hole in the bucket, dear Liza, dear Liza,
There’s a hole in the bucket, dear Liza, a hole.
– children’s song, Bergliederbüchlein (c 1700)

In my prior article, I introduced the concept of a scope bucket to explain the concept of project scope to your stakeholders.  In this article, I continue the theme with some tips for managing and delivering the scope in your project scope bucket.

Read more



A Bucket of Scope

May 13, 2014

An architect relies on a clear understanding of scope.  In prior articles we have discussed the business context diagram, a great tool for establishing solution scope.  We also provided a technique for setting expectations regarding the scope of architecture activities.  In this article, I intend to expand on the importance of understanding (or establishing, if you are in a project lead role) the scope of a project.

Read more



“Make it Work Like Our Current System” and Other Requirement Pitfalls

March 18, 2014

This is the final article in in the series for implementing “Custom Off The Shelf” (COTS) solutions; a follow up to our Buy vs. Build Your Software  and “Off the Shelf” Implementation Pitfalls articles. In this we want to address requirement approaches that are sometimes proposed, but rarely successful in such an implementation.

Read more



Issue Resolution – Celebrate Your Success

March 3, 2014

This blog is the third in a series of posts designed to help technical leads get over the hurdles that inevitably pop up during any complex implementation; a series that was started by Understanding the Problem and continued in Determining a Solution.

With the course set and the implementation of the recommended solution underway, it’s time to finish strong.  Read more



Issue Resolution – Determining a Solution

February 19, 2014

This blog is the second in a series of posts designed to help technical leads get over the hurdles that inevitably pop up during any complex implementation; a series that was started with Understanding the Problem.

Once the problem is sufficiently understood, it’s time to roll up your sleeves and get down to business. Read more



“Off the Shelf” Software Implementation Pitfalls

February 3, 2014

This is the long-awaiting (or at least long-promised) article on implementing “bought” products; a follow up to our Buy vs. Build Your Software article.  Many large organizations rely heavily on external vendors for large scale software implementations of “Off the Shelf” packages – very frequently modified for competitive advantage and/or to align with internal business processes. These are some common pitfalls to these Custom Off The Shelf (COTS) implementations.

Read more



The Art of Accepting Feedback

January 24, 2013

As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. Read more



Lies, Damn Lies, and Traceability

December 17, 2012

In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements that creeped into your project.

Too often, however, project managers see the steps in a project from the point of view of items that simply need to be checked off: Read more



Next Page »