These last few weeks we have discussed a lot of information on current views and future state architecture. One of the focuses has been on the ability to justify decisions based on how it ties back to business strategy. Last week I talked about some techniques I have used in the past that provided a set of artifacts that could be utilized across project efforts. These SWOT storyboards and GQM matrix also assist with continued buy-in and help the teams tie back to business strategy. One thing I have found missing from these discussions and readings is "where to start?". We often hear the term "low hanging fruit" but what is it and how do you find this fruit? This is a question I often had when working with different customers. So my team and I came up with an approach that we found quite useful and delivered a metric we could use to assess the complexity of a proposed effort.
This project complexity effort was the key to project alignment, and solution delivery. It seems to me that this could also be useful in determining both where to start and the extent of the gaps in getting to a particular future vision. Project Complexity Assessment is the process of determining a specific project’s likely complexity. It rates a project’s complexity by assessing the project’s anticipated requirements complexity against its anticipated environment complexity. It then goes on to identify the most likely classification by establishing a complexity type for early estimation and planning purposes. This helps ensure effective expectation management from the very early stages of project inception. This also allows one to find those "low hanging fruits." This image represents the different levels of complexity.
Once you have determined the different project type, it is then easy to present this in a graph. This demonstrates which complexity type the project best fits and also maps the project’s affinity for both requirements and environment complexity.
There are certainly many articles and books out there about project complexity. This one on Amazon
http://www.amazon.com/Project-Complexity-Assessment-ebook/dp/B00C2HXX58/
is a result of research from the International Center for Complex Project Managment located here
https://iccpm.com/content/complexity-assessment-tool. To me it appears that a lot of this information is just focused on the project vs how it ties into the overall Business Architecture or EA.
Once again these are just some techniques I have used effectively in the past. I believe they can add value in the EA process by potentially identifying the least complex place to start. In turn, this can offer the greatest chance of success in the shortest amount of time and as a result, add credibility to the EA team.
Please let me know your thoughts.
Thanks for reading!
Hi Joe,
ReplyDeleteIt is very interesting to learn from your post how a situation can be analyzed based on project type and project complexity. I liked the framework that you have created for defining the project type and then mapping the complexity based on the environment and requirements. This seems to be a very intelligent way of assessing the scope and efforts on EA initiatives. I have already decided to use these ideas in some of the initiatives I am currently working on and also on the ones that have been identified for 2016. Thank you very much for sharing your experience and novice EAs like me will be greatly benefitted from your experiences.
Thanks,
Veena.
Veena,
DeleteThanks for reading and also for your comments. I'm glad you see some value in some of this. I have found it to be very helpful and I hope you do as well. If you email me I will send you a couple of slides that add some additional detail that may prove helpful.
Joe I think it's definitely important to find that "low hanging fruit". I discussed the need similarly in my blog this week and referenced yours. We had done something similar in intent in our organization though different in execution to what you describe here and that was an "architectural impact assessment". A series of fairly leading and weighted questions were filled out at project initiation by an EA to determine how much value would be derived by our involvement in the project. It was an attempt to jump in where important and let go of the reigns where different priorities overruled. Where can we have quick wins and where can we show that we will not be a road-block.
ReplyDeleteThanks for reading Bill. I like that "quick win" approach. Has it been successful to date? Are there time where you do deem that EA involvement in a project would not be useful?
DeleteJoe, One of the ways that we have prioritized the future state scenarios is to poll the stakeholders on 2 factors. The first being the level of pain caused by a certain pain point, the second is the criticality. I relate the axis to going to the hospital where doctors asking you your pain level on a scale of 0-10. They inherently know what the criticality of certain conditions (e.g. heart problems over broken legs). I think it is important to use both because just because something is difficult does mean it is that important. I like your complexity analysis as well. Thanks for the research links.
ReplyDeleteThanks Susan! That is a good analogy that most folks probably understand easily. Do you ever find that something is a 10 but just able to be addressed? If so how do you communicate that to the business? Is it that you have to break it down into smaller pieces to address?
DeleteThanks again for reading and commenting.
Joe,
ReplyDeleteA very useful discussion. There are days when I actually do more project management than architecture work, and I appreciate new insights for project complexity heuristics. I particularly like the way the matrix makes use two main factors i.e. Requirements vs. Environment - this is a surprisingly fresh look, given that it seems so obvious that it makes us wonder why we have not been using this insight before. The usual practice of course, is the old ROM technique (Rough Order of Magnitude) for purposes of deriving estimates, where complexity factors are identified, and for each, points are assigned to a range of complexity levels (very low to very high). Your supplied matrix provides another layer of analysis.
This is quite useful since complexity correlates with risk, and risk assessment is applicable for validating the proposed future-state architectures.
Thanks again for your post.
Ian
Thank you Ian. This really came about from being burned on projects. A professor told me once that if I really wanted to get a good dose of business skills I should go into consulting. It is always changing customer to customer and project to project. It was during this time of my career that we first came up with this approach. It has served me well to date and continues to evolve to the point where we recently built this into an excel spreadsheet for modeling. I agree with you on the PM vs architecture work balance I have those same thoughts almost daily it seems! Thanks again for the comment and for reading!
DeleteHi Joe,
ReplyDeleteI like the complexity assessment graphs a lot. I can see the value of having these in meetings with executives and IT management to determine at a high level the complexities of projects on the list and effectively make decision-making sessions a collaborative approach with an understanding on the baseline of what might need to be traded off or added to the priority list of the organization projects. However, for a brand new EA initiative for a company where EA practice is not in place, I would personally lead with what needs to be done to get things on the right track as a priority, and then use these complexity diagrams down the road as a priority weighing factor for the business/IT needs and wants. So essentially, I would apply them to anything that is not core EA initiative activity but rather after the initial EA implementation phases have been completed.
Hello Ziad-
DeleteThank you for reading and commenting. What you are suggesting makes a lot of sense. If you look back at my other blogs I think we would agree. I would use this much as you would after driving through some SWOT analysis and GQM to establish a single vision of those priorities. This would then be used to assess the complexity associated with some of the outputs of those artifacts. So what you say does make perfect sense to me. Get the initial activities established and then use something similar to this to establish some idea of the effort. At least that is what I am taking from your comment.
Thanks again for commenting!
Thank you for sharing this model of determining low hanging fruits. It is important for the EA team to establish its credibility and value early on and this approach for identifying low hanging fruit will certainly help with delivering value early. In cases where more than one low hanging fruit projects are available, additional criteria can be used to help identify which project to select first. Business priority, availability of resources with the required skillset, dependency or relationship with other projects/initiatives are some such criteria.
ReplyDeleteThank you for sharing this model of determining low hanging fruits. It is important for the EA team to establish its credibility and value early on and this approach for identifying low hanging fruit will certainly help with delivering value early. In cases where more than one low hanging fruit projects are available, additional criteria can be used to help identify which project to select first. Business priority, availability of resources with the required skillset, dependency or relationship with other projects/initiatives are some such criteria.
ReplyDelete