My last blog post was about the creation of a process for “development” that is outside of the IT area. I have been contacted both directly via email (Joshua@upmentors.com) and by comment on the original post made at www.upmentors.com, all requesting additional information. In an effort to keep these posts short as this could easily be a rather long whitepaper or article, this will cover an overview of the approach. I will then subsequently make short posts for each key step to provide a little more context. Please note that the process I will describe was created for a client and therefore I cannot upload the published content…
The key steps were as followed:
Analysis of the current policies and procedures that were currently in place to govern this type of development as well as selecting sample projects that have executed to see what occurred in real life. The assessment was short and focused; there was not a lot of structure in place, which was a known fact from the beginning so no need for a multi-month assessment to boil the ocean.
Assessment Results / Key Practice Recommendation
Assessment results were used to identify areas of concern, practices that would mitigate concern, development cases, and appropriate level of documentation (negotiated with senior and executive management, internal audit, and project team SMEs to make it minimal while providing enough context for comfort).
Having good processes is important, making it effectively deployed is crucial. A process management tool platform, Eclipse Process Framework Composer (see www.eclipse.org/epf), was utilized for authoring, tailoring, documenting and deploying the development process framework.
A standardized and managed development process library of reusable content was created, based on existing company policies and procedures as well as industry best practices. This approach provided an extensible knowledge base of intellectual capital. It also supports the growth and management of the development processes (continuous process improvement).
We used a combination of method content, including applicable aspects of the existing policies and procedures (which were disjointed and in many different documents), select practice based content from OpenUP (see www.eclipse.org/epf/generla/OpenUP.pdf) which was tailored for this type of development, and newly created context that was very domain specific and prescriptive. This approach significantly reduced the redundancy and existing conflicts in the varying policies and leveraged the proven practices selected from OpenUP.
Once the method content was created we designed 3 development cases, one for each key type of development project. Development Cases are process engineering mechanisms that enable tailoring of a process and can be employed at various levels (i.e. project pattern type – build/buy, small/medium/large, etc. and or the next level down, each specific project to makes project level tailoring of the process to fit the needs of that project). Each of our 3 development cases selected specific aspects from our process library (all the method content that we created) which essentially made 3 sub process to choose from. The resulting methodology used risk type classification to determine which of the 3 development cases would be applicable, ultimately determining how much “stuff” a given project would have to complete and document.
For those readers that are already familiar with OpenUP and EPF-Composer, we had one tab in the navigation pane that contained content that was applicable to this type of development and 3 more tabs, one for each development case that had only the content applicable to that development case.
In the coming days I will make additional blog entries on these key areas. I will also blog about another new process that is being created for the Financial Modeling within this same organization. The process that I have been writing about has been so well received, additional areas see value in putting a little structure around the work that they do…