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
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
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.
Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objective of the change, and what are the requirements a change must meet to satisfy the objective.
Implementing the change usually starts with someone needing to know what the change is going to cost!
Risks are part of life. There is uncertainty everywhere. And as more and more of our lives and businesses depend on IT, the risk of IT failures and problems is a critical thing to be able to identify, understand, document and – ultimately – manage.
Architectural Risk is a critical discipline in the Systems Flow process. Its a huge selling point in the “design process” sales pitch we are often called on to deliver, usually not to prospective clients but rather to recalcitrant stakeholders or projects sponsors who need to be convinced to spend time in their projects sorting out architecture and design before diving into coding. Read more
If you work in a professional environment, you inevitably have to communicate the status of your work to your manager. If you are in the professional services business, then you have an even tougher “manager” – your client.
Welcome to today’s blog. Sit back and relax. Close your eyes. Take some deep relaxing breaths. Envision a Utopian architecture project delivery:
- Scope is clear and agreed upon,
- Requirements are carefully crafted,
- Read more
I previously shared a simple method to conquer the task management beast in An Old School Method for Task Management.
Beyond the basic methodology, I do have some specific pointers that help me, many of which I have extracted from the many task schemes that have not worked out for me (many of the ideas come from David Allen’s Getting Things Done approach). Read more
Organizational capability is a core competency for an architect, if not for any human being who wants to be remotely effective.
You’re the project manager of a large project and from a requirements perspective it looks like everything is on track for success:
- Business Requirements. Written and Approved. Check.
- Functional Requirements. Written and Approved. Check.
Seems like everything is covered. Except… where’s your traceability matrix? You have one, right? Read more