Project Plan Activities for an Architect

I’m the lead architect on a large CRM project that is about to start the Design phase (or in my RUP world, “Elaboration”), and my PM asked me what architectural tasks belong in her project plan for this phase of work.  I don’t always get asked this question on projects as there’s usually either a large “system design” bucket, or, just a couple high level tasks assigned to the project architect.

So, I have three options here:

  1. Ask for one giant “system design” task that goes for 4 months.  On the plus side, this let’s the design process be fairly fluid and doesn’t put the various design tasks into a strict linear path.  However, obviously this makes tracking progress quite difficult, and, would force the PM to add 5-10 different “assigned to” parties because the various design tasks involve different parts of the organization.
  2. Go hyper-detailed and list every possible design milestone.  The PM started down this path, but I’m not a fan.  I don’t want every single system integration, or software plug-in choice called out as specific tasks.  Those items must be captured and tracked somewhere (of course), but the project plan doesn’t seem to me to be the right place.  It makes the plan too complicated and cross-referenced and makes maintenance such a chore for the PM.
  3. List high level design tasks which allow for segmentation of responsibility and milestone tracking.  I naturally saved my personal preference for last, because that’s typically how my lists work.  In this model, I break out “system design” into its core components.

So I provided the list below to my PM.  I broke out each core task and flagged which dependencies are associated with each.  If you “mouseover” the task title, I have a bit more text explaining what the details of that task are. Some of these tasks can and will happen simultaneously, so don’t totally read this as a linear sequence.  I’d be interested in all of your feedback.

  Task Dependency
1 System Design  
2   Capture System Use Cases Functional requirements

Non-functional requirements

3   Record System Dependencies Functional requirements
4   Identify Data Sources Functional requirements
5   List Design Constraints Functional requirements

Non-functional requirements

[Task 2] [Task 3] [Task 4]

6   Build High Level Data Flow Functional requirements

[Task 2] [Task 3] [Task 4]

7   Catalog System Interfaces Functional requirements

[Task 6]

8   Outline Security Strategy Functional requirements

Non-functional requirements

[Task 5]

9   Define Deployment Design Non-functional requirements
10 Design Review  
11   Organization Architecture Board Review [Task 1]
12   Team Peer Review [Task 11]

Hopefully this provides enough structure to keep track of key milestones, but not so much detail that I’m constantly updating the minutiae of my progress.  How do your projects typically track architectural progress during a design phase?


Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

8 thoughts

  1. Nice high level plan! Most of the tasks seem to focus on the perimeter of the solution though. This will give you a nice crispy system boundary shell that plays nice in the landscape, but I’d add a task or two so you don’t end up with a squishy center!

    Maybe add the delivery of a high level internal component model which will actually help drive some of the other tasks you have. For example, it will show which components support your interaces, help drive technology selection and influence your deployment. You can also make a technical risk assessment which will drive the planning for any needed PoC’s, which your PM will be very interested in.

  2. Good point Ian. I should add the “functional decomposition” model to the list. Technical risk assessment is a good deliverable, but wondering if that is something maintained throughout the project, and thus tough to pin down for project planning purposes.

    1. We typically use the Architecture Essentials Practice of EssUP to help drive through the architectural processes.

      Following up Ian’s point this typically leads to identifying key architectural risks very early and finding ways to mitigate them. This can be as simple as a COTS product review and selection or as complex as looking at the key critical paths in the business use cases and creating a PoC that is a spike through the system to drive out the areas of design with highest risk.

      We’d usuall do this pretty early on in design so it can help drive the development and iteration cycles, identifying and addressing key risk early.

      I usually like getting some of this activity on a plan because showing a customer you’re addressing risk early can only ever be good!

  3. I love squishy centres 🙂

    Depndencies are everything. Avoid the problem we have on the project I’m currently engaged on. In order to release money to fund the next stage of the project, we have to first pass a critical design review. What is that next stage? Elaboration. The first ‘bucket’? Produce the high level and low level designs.

    Go figure.

  4. Hi Richard

    I think the point above about risks is a good one. Although the risks are usually maintained throughout the project most places ive worked usually take a snapshot of the risks at key milestones for auditing purposes and project reviews.

    I would normally expect that your team identified some technical risks during inception and will probably find some more during elaboration (or what ever your methodology calls them). I think in your current phase if you have risks that warrant a proof of concept to mitigate the risk you should outline these in your plan just to say you have n number of POC’s and if it will be done now or in a later iteration.

  5. What sort of architectural deliverables do you hand over to the development teams? UML use case and activity diagrams? Schema stubs?

  6. Hi Dave. We typically handle over a System Design Specification which includes system use cases, corresponding activities diagrams, dependency models, interface models, and in some cases, WSDL or data structure stubs.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.