Architecting your process

By on November 14, 2013 in Architecture Process, Software Architect

Delivering even a small software project takes a team and when working with a team process is your best friend. A clearly defined and repeatable process must be adopted if you are going to succeed. Keep this in mind as you approach each new project; keep a list of the things that work and develop them into a processes that you can perform on each and every project. Your process will be specific to your organization and the methodology you are using but even with a defined methodology there is lots of room to customize it. Developing a set of repeatable procedures will save you time and frustration in the future.

It may sound like overkill but personally I keep a working set of documents that guide my projects and duties. These are simple bulleted lists that I continually change as I discover practices that can help to make me more effective. Whenever I work on process, something that I know I am going to perform a number of times, I spend the extra time developing a simple bulleted list of steps that I follow.   This is a working set documents that I continually modify every time I repeat the process and discover something that can make it more efficient. There are three main benefits that I realize from this practice:

1) It helps me be more effective because I continually evaluate and improve my processes.

2) If I can follow the steps then so can someone else. Once documented this process can be assigned to someone else to perform.

3) These documents are great teaching aids because I can share them with my peers that are performing the same duties I am.

This practice helps me with projects because I often share these documents with the team to instruct them on the procedures that we will follow.

One example from a recent project is related to project sizing. I am often asked to size solutions at the very onset of a project, even before the project has been approved. This is necessary because the organization needs a way to assess the impact of the project relative to cost and resource needs. This is quite common in the enterprise and allows your business to decide if the value being provided is greater than the cost. I typically provide these high level estimates as a range of hours because, at the onset of a project, there is still too much unknown to give fine grained estimates. One of the dangers of providing estimates like these is that well meaning enterprise architects, project managers and even directors often add hours or worse yet, they take the lower range of the estimate and use it to create a project plan even before the project team has been engaged. In this particular case a project manager took the lower range of my size estimate and provided it to the development manager whose team would implement the solution. Naturally I was confronted by this development manager and asked how I came up with the estimate. I explained the process and sent him my design and estimate figures but more importantly, I learned something. I immediately adjusted my project sizing process to include a review with subject matter experts if it fell outside my area of expertise. I additionally added a step to include the development managers on my distribution list. Below is an excerpt from my project sizing process:

  • Project Sizing
    • Use the following project size buckets for high level estimates
      • Tiny: <150
      • Small: 150-300
      • Medium: 300-700
      • Large: 700-1500
      • Extra Large: >1500
    • Request estimate review with sme from dev team if needed
    • Provide estimate to development managers that are impacted by estimate

These days I use Google docs but you can do this with OneNote or any other tool that allows you to quickly create and organize simple bulleted lists.  Each of my process documents are contained in a folder named operating docs.  This folder contains many documents that outline my processes, one of which is how I perform project estimates. Currently I work on a team of 6 software architects, all of which are asked to size projects like this many times a week. All of us perform this task quite independently because there are no written processes in our organization that identify the steps that should be taken when providing estimates. My goal is NOT to force everyone to conform to my process but to identify a process that can be repeated consistently and improved upon as needed. When a new, perhaps junior architect is assigned to the team and asks how we go about sizing projects, I can provide him with access to this simple process doc that I maintain. I dont always need to refer to my operating docs when I am performing estimates but when I do they are easy for me to find and improve.

If you are a skeptical then I would suggest that you adopt this tactic for a few months with just a few processes. You’ll discover the tremendous value for yourself.



If you enjoyed this article, subscribe now to receive more just like it.

Comments are closed.