Identify Indirect Stakeholders with System Context Diagrams
A Systems Flow consultant has skills that tend to fall in the triangle of technical, business and organizational excellence. One common and repetitive case of project dysfunction where this overlap brings real benefits is that of the “Operational Business Stakeholders Missing from Business Requirements.” Here’s how it usually goes:
- Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
- He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
- The requirements (hopefully) clearly state the end-user and product/service-centric objectives
- But how the end-users and the new/enhanced product or service will be supported operationally is completely missing
Read more
“Make it Work Like Our Current System” and Other Requirement Pitfalls
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.
Lies, Damn Lies, and Traceability
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
Type A’s Needed!
We write frequently on this blog about our proven method to deliver IT architectures based on industry-standard tools and approaches like UML and IT Risk Management. We also write about the critical intangible skills that an architect needs to succeed, such as meeting facilitation, diplomacy and organization. One needs to be steeped in all these areas – as well as to form a strong “magic triangle” of technical/business/management skills to really succeed.
Read more