After some deliberation, what developed was more of a “risk appraisal”.  I was skeptical about the value of doing what appeared to be just an adhoc review of project team documentation and informal interviews of key/lead project team representatives. 

The focus became identifying risks when project number one would be completed and project number 2 would begin.  Just a few examples of risks that we looked for:

• Incurring technical debt, where activities would be put off to a future project and with the passage of time greater levels of effort would be required and more funding as opposed to just doing something in the present time
• The project team completing activities that were valuable but did not produce any formal documentation and project number 2 (or any successor in the program) redoing the same work
• The project team not completing activities that they should have, the next project having the expectation that something was done and not planning or budgeting to do that work

The “risk appraisals” were quite valuable, although not an assessment, they provided good visibility into risks that had a high probability of materializing and significant impact to the subsequent project.

Joshua Barnes

Co-Founder

joshua@upmentors.com

I recently observed a person who was in the role of a Process Mentor that was assigned to support a very large project (over 60 core project team members) which had a scope that would have a very significant impact on the existing system’s architecture.  This person when working with Analysts was VERY competent, provided solid coaching, and was able to really help the requirements elicitation and documentation aspects of the project.  However, this person was the single Process Mentor and when it came time to provide the same type of services to the System Architect, Enterprise Architect, and Lead Developer, well they were at a loss. Sure, they could point to the context in the process that seemed appropriate, but in reality they had little experience in the area of design and architecture (other than some coding long ago early in their career). 

One of the simple solutions I try to get buy-in from decision makers on is using a team approach, where, one Process Mentor can at least at a high-level be the process go-to person for a project, but where the rubber meets the road they should stick to whatever their deep expertise lies in and call on other Process Mentors who have a different skill set to support the rest.  I have often found that process areas can have someone who is great in the Requirements and Analysis aspects, a more technical background person for the architecture, design, and coding, a testing professional, and then a good project manager type. 

Somehow the perception of this is that it would be way too expensive to have multiple resources allocated to a project as opposed to a single person.  Even when the discussion focuses on only a portion of a given person’s time would need to be spent on a day or weekly basis, and depending on the point in the project’s lifecycle, the skillset needed will be changing as well.  In reality, it is less expensive and provides results that can be measured (both quantitatively and subjectively) however it is often a challenging concept to get to move forward… 

Is this happening in your organization?

Joshua Barnes

Co-Founder UPMentors

joshua@upmentors.com

Most of the focus I have working with clients over the past few years is how to adopt agile development techniques that can scale up for large organizations that still require a certain level of ceremony, documentation, and control objectives that must be complied with.  The Rational Unified Process, “RUP”, has been a leading commercially available process framework for more than a decade; however, over the years there has been more and more stuff that has been added making the available content very robust.   While getting a lot for the considerable money spent to buy RUP is good, the downside is that it has become increasing difficult for organizations to adopt RUP without way too much “process” coming along for the ride and spoiling the potential return on investment.

This is not necessarily RUP’s fault, if you adopt RUP with a well thought out strategy you can do it in a way that is agile and adds tremendous value to an organization, but the inevitable results far too often are too much process overhead and lack luster results in project execution.  So what to do?

RUP as well as the open source version OpenUP (see www.eclipse.org/epf/general/OpenUP.pdf) have a wealth of method content that can be used to pick and choose from to publish a process that will meet the needs of your organization and enable agile development techniques.  OpenUP has far less content than RUP has, but that is not necessarily a bad place to start.  Just like picking a process management tool such as RMC or the Eclipse Process Framework Composer (see Using a Process Management Tool), selecting a process library to start with that is small and manageable and can be added to in the areas that will have an impact for your specific needs is actually a great place to start.  If you are in a large organization, the content that is freely available in OpenUP will most likely need to be supplemented, but often not right away.  Using the “Practices” that come with OpenUP (smallest pieces of a methodology that can stand on their own and still provide measureable value to a project team) can usually hit the key pain points of most organizations.  From that starting point, I often add in domain/organization specific aspects that come from existing policies, procedures, and standards.  After that, the additional wealth of information that is available with RUP can be used effectively.

Practices are a very powerful process adoption component; they enable project teams to adopt a part of the entire process in a more manageable way, one or more pieces at a time.  They also enable selection of the pieces of the process that can immediately be put into an adoption strategy, which solves the highest ranked pain-points at a rate of organizational change that is more practical.

I will continue the discussion of practices in my next post, as they are the corner stone of the adoption strategy we most often see meaningful results with and there is quite a lot of well packaged agile techniques content that is ready and free to use.

Both of these tools are used to author, tailor, document and deploy “method content” (the stuff that is the process) as a framework.  Tools such as these really make process engineering and architecture take on a larger return of value.  There are countless ways to push out a process, everything from simply writing it down on a wall (maybe a giant whiteboard) to publishing as a humongous document such as a pdf that is out on the company website, to a process website.  That last one is where these two tools have a lot of robustness.

Although printed manuals are still the comfort of many people, moving your organization’s methodology to a web based format provides easy navigation, indexing, and search engine capability which enables the day in and day out users to find information quickly and easily such as: templates, examples, and guidance on what tasks to do, when to do them, and what is the resulting work product (amongst lots of other meaningful stuff).

Often when I am discussing using either of these tools as part of a process improvement strategy with clients, the simple analogy is the difference between looking a something like the old Sears Catalog that came out once a year or going to Amazon and finding what you are looking for (plus all sorts of other content that should help with items you are looking at).

Using a process management tool such as these also enables a standardized and managed development process library of reusable process content that can be based on existing policies and procedures as well as industry best practices.  Once created, this provides an extensible knowledge base of intellectual capital.  It also supports the systematic growth and management of the development processes (continuous process improvement) while maintaining methodology alignment throughout the organization for differing project patterns (large, small, new development, enhancing an existing app, build, buy, IT development vs. small app dev outside of IT vs. other types of development – fin modeling).

RMC is the commercially available tool from IBM and the Eclipse Process Framework Composer is the open source version (see www.eclipse.org/epf).  More and more I have found that starting with the open source version, and using the process library content that comes with it as a starting place has worked really well.  Plus, it is free!  Some clients do want to purchase licenses from a vendor so they can pick the phone and chat with support, so that may a constraint you could face.  If you think you can get value from a process management tool, I suggest starting with the open source version and when the time comes to comply with the push to buy something, and then reach out your sales person.  No need to rush when there is so much that can be done initially with the eclipse version and what you do in the eclipse version can be imported into the for money version…

Are you thinking what’s a financial model?  Well, they are approximations of a complex real-world process…hmm that sounds rather academic.  Basically, models are used to reduce complexity using really really sophisticated mathematical and statistical calculations to estimate something or predict an outcome.

As it turns out, in practice, financial modeling is a lot like software development, unless you are chatting with a financial modeler and then they are nothing alike .  Models incorporate lots of functional features, data extraction, data transformation, calculations, and output in various formats.  Further, although there are modeling specific development tools and environments, these often have limited performance when scaling up for multi-user scenarios so models are frequently implemented in SAS or C++.  Yeah, that sounds very similar to software development to me.

So what is the big difference in financial modeling vs. software development?  The resources.  People that are typically engaged in financial modeling are not formally (or often even informally) trained in software development, they are economists and mathematicians and in a few cases I have experienced physicists.  Organizationally they are normally outside of the IT area and are not subject to the same IT general controls.

I am just beginning to help a client use the process we created for development of small apps outside of IT (see More On the Process for Development Outside of the IT Area) and apply it to the financial modeling area along with all the necessary tweaks to fit that specific type of domain.  I will continue to write about how it is developing and the path we take to get to our first release…

The key steps were as followed:

“Mini-Assessment”

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).

Delivery Mechanism

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).

Method Content

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/general/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.

Development Cases

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…

What we found was that a minimal process that was very agile in its approach that required the bare minimum amount of documentation added very little impact, but now provides a comfort level to executive management, internal audit, and external audit as well as putting some structure around the risk management and mitigation.

This process is in the initial adoption phase and will be refactored based on the results and lessons learned before it takes on program level coverage.  In future updates, I will blog the good, the bad, and maybe even the ugly on how it continues to evolve in practice.  Based on initial results, I think that many organizations could benefit from the approach we used…

Process implementation, process improvement, and process reengineering initiatives are no different than other types of project work when it comes to cutting budget. These types of initiatives typically span multiple years in larger organizations due to the sheer size of the target adoption population which can be from a thousand IT professionals to many thousands. So what happens when the budget for the initiative is reduced or cut too soon? Same as any other type of project work, the results and return on investment will come up lacking at best, will begin to steeply degrade at a medium, and at worst the organization is worse off than where the baseline starting point was, after tremendous time, effort, and money have been consumed.

The strategies we employ with our clients when adopting new and better process solutions or when we are helping to turn around an existing UP/Agile based solution adoption; we always have a vision of self sufficiency incorporated where we are training and mentoring the internal resources that will take over the roles and responsibilities that we engage in. This particular aspect sometimes gets eliminated by organizational management once initial adoption measurements show favorable results. External support can be reduced to quickly and the targeted internal resources have not gained sufficient experience in the role or training and mentor and sometimes not even in the role of a lead practitioner.

This often has significant negative ramifications to the initiative; it is amazing how progress that may have taken 12-18 months can be reduced so quickly. An analogy I like to draw is a group of people that encompasses the adoption team of external training/ mentors along with the internal mentors in training combined with all the other supporting roles plus all the project team practitioners that are valiantly trying their best to adopt this new process all pushing a heavy boulder up a hill. Just before reaching the crest where the momentum will begin to help continue rolling the boulder, some of the needed help to get it over the crest is removed.

What typically happens next is the forward progress of rolling the boulder is slowed, then comes to a brief stop, and ultimately begins to roll back towards the starting point. There are undoubtedly project practitioners along the way that gained enough experience and exposure to continue to use the new methods in their work, but as an organization, the ROI has generally peaked and begins a downward trend.
The new process begins to take on a negative connotation and the bandwidth of the remaining adoption team members is beyond an adequate level to provide minimum quality. On top of that, the fact that their level of expertise necessary for supporting the continuing project teams that are still on the adoption path is too low, and you can see where this is going, all the good work begins to unravel and finger-pointing starts to rule the day…

A lot of the clients that I engage with are often in need of help to turn around an initiative that has not yielded the expected return on investment.  Ok, that is a soft way of saying that usually once things have gone awry for a while, they need a turnaround team to fix the current state and bring focus and a strategy that will yield results.

Results derived from process initiatives in software development don’t provide returns overnight for larger organizations.  These types of initiatives, with populations of software development professionals that will be impacted range from 1,000 to many thousands take time, and can span from 12 – 60 months.  Just like any other initiative that has such a long timeline, the leader must have a vision that they are driving to.  Ok, let me state that again, the leader MUST have a vision, and be committed to making and supporting decisions that will bring that vision to fruition within an achievable timeline.

One of the sports that I enjoy following is Formula 1 racing.  F1 is at the top of the food chain in motorsports, they have the biggest budgets (some in excess of $600 million a year and over 1,000 team members) just to race 2 cars in a single season.  Just like any other sport, there are the teams that are the front runners with a real chance to be the season’s champions and there are those that are the back markers, the teams in the last places on the results board.  One team, that as long as I have been a fan of F1 has always been at the low end of the results, consistently coming in last and second to last place.  The team was purchased, and the new team leader in an interview discussed the vision he had for the team which included hiring very well respected people in the industry, incremental improvements, and instilling the team with a new philosophy.  The timeline to reach this vision was a few years, and every year, up through this one, they did indeed improve.  This year they were real contenders for the championship title, and lost by a very slim margin.  This was a team that just a few years ago would have had a good race if one of their 2 cars came in 3rd from last.  Now they regularly win races and are one of the most competitive teams in the series.  All it took was vision.

I recently worked with a client that had a lot of the ingredients for real success, the success that can be discussed based on measurable results that are meaningful to the organization.  However, where this was an initiative with a lot of promise and on an upward trend to finally see returns on the significant investments they had and would still need to make, the leader of this initiative, who recently took over lacked any vision.  There has been a very visible degradation to the process implementation team, the project teams that are adopting as well as those who have already adopted.  Absent from the list of roles who have taken notice is executive management.  There is no doubt they will be taking notice in the very near term, but to date there has been very good “filtering” upward and the ride on the wave of earlier momentum is still paying dividends, albeit that is coming to an end.

The cost of this degradation will be material, in my experience as well as intimate knowledge of the environment; it will take hard work and financial commitment to get the work back on course.  Lack of vision is very costly indeed.

Joshua Barnes

The analysis found that there were parts of each methodology that provided the right amount of process robustness and guidance for the types of projects applicable; however, there was a fair amount of inconsistency across the varying methodologies and many core/fundamental areas that need augmentation in the areas of prescriptive guidance, good quality examples, impacts of not performing a given task (and resulting work product) as well as reasons for not needing.

The whole process of assessing the current state was a very healthy activity for the organization. There were many people at both the practitioner level as well as management level that knew there was room for improvement and areas that needed immediate remediation. There were also people that initially were reluctant to believe that anything at all needed to be changed and everything was “just fine”. In the final management discussions where all of the findings and supporting evidence was presented, no one could contest that changes had to be made.

The analysis and resulting recommendations were used to create a business case for change and an action plan which included creating a common process framework so that the organization would have a methodology that can support their varying development types with consistency and efficiency by leveraging common process practices and method content where possible. We will be using the Eclipse Process Framework Composer (EPF Composer) and as much OpenUP method content to supplement all of the existing policies and procedures.