Archive for the ‘BPR’ Category.

Software Engineering and Software Engineering BPR Techniques that Actually Work

Most of you who read my blog know that the only thing I usually plug is IPAWS-OPEN (and the link to Donate Life, of course). I am making an exception because my good friend and mentor, Doug Rosenberg, is offering his public courses in DC the week of 16-20 May 2011. If you want to discover software engineering life cycle techniques that are light enough to actually be followed and, at the same time, detailed enough to keep a project from failing, check him out. Link as follows:

Oops! BPR and Software Process Mentor/Trainer/Consultant Now Available

The Virginia DMV just got another budget whack. It means that I am part-time for a while and eventually no-time, unless they can find a way around the latest hit. Looks like I made a mistake when I did not take the offering I referred to in my 30 August post. It was a mistake of loyalty. I am going to miss the folks I worked with a lot. So, I am now available full-time to for any other folks who might have a use for my help. DMV references are available.

Whew! Some Decisions are Hard to Make

My last post was some time ago. At that time the Virginia DMV had asked me to stay for another 1500 work hours. But, there was a bit of a glitch. The Virginia budget crunch meant that the extension package approval had to go to the Secretary of Transportation for approval. This took two tries and a lot of effort by my DMV sponsors, but they got it through. In fact the package actually was sent to the Governor’s budget office for final approval, but it got done!!!!

In the meantime, I let a couple of friends know that I could possibly be available. I got two very good offers, one in Emergency Management for a long term contract. The other shorter, but including at least two trips to Australia. In the end, I chose to stay with my DMV colleagues. They have become family to this grandpa in a very real way. There are even a few family squabbles to deal with. But these are good people, and this opportunity is so unique that I cannot walk away until my job is done. It is also true that I owe them a lot for all of their efforts in support of my extension. So, I think that I made the right decision.

Still Going Strong at Virginia DMV

I originally thought I was in for 3 to 6 months. It has now been one year and I have been approved for a one year extension. Here is a secret for all you consultants out there. Empower your customers! Emphasize the value that they bring to their own projects. Teach them how to do without you. My experience tells me that you may find that the environment you help create gives you more opportunity in the long run. Not less. My point — you do not have to be come indispensable (“all contractors are dispensable”). You just have to add more value than you cost. Multiplying the value of others is a good way to do that.

BPR and Requirements Development Process Definition

The third time is the charm. Ten years ago, I wrote a paper on systems analysis and requirements definition for the Army Systems Engineering folks in Monmouth, New Jersey titled “Just in time Analysis.” It used mission decomposition in IDEF0 to identify needed use cases as an inventory of work to be done. Five years ago, I developed an internal process document based on the Iconix Process for Battelle to use in development of Disaster Management Interoperability Services software for the Department of Homeland Security.

I am back at it. For more than a year, the Virginia Department of Motor Vehicles (DMV) has been following a customized version of the Iconix Process for its BPR and Requirements development needs. The process grew out of the need for DMV to control its own destiny in its new software redesign effort. It had to start simply enough for business analysts to use it to drive business requirements. A prime goal was to ensure that it was business-driven; not IT driven. As it grew, however, the process required the power to handle complex issues, particularly the refactoring of multitudes of silo-style business processes into a set of requirements geared to a Service Oriented Architecture (SOA).

We are getting there. It is amazing how the process has evolved over the course of a year. We have documented our processes, and their evolution, using the same tools we use to document the actual DMV requirements. I am now in the process of gathering and publishing that information in a single coherent written manual. As I write this manual, it is more and more amazing what the folks at the Virginia DMV here have been able to accomplish in the last year. There is a lot, and it is good. I pray that the document I am writing will do them justice.

DMV BPR Support Continues

Looks like I will stay with the DMV through October at least.  I am currently writing the formal process documentation as well as helping the DMV folks prepare for collaborative design activity with their chosen development vendor (still TBD).  This is truly a big project.  We have identified over 1000 business use cases so far.  The software use cases to be built over the next few years my reach 10000 although half of them will probably be out of scope initially.  Comprehensive to say the least.   Wow!

A Individual or an Organization “is-a” Party; all have Roles.

Spent the last couple of weeks helping to design a single place in the logical data structure for all aspects of information a DMV might want to consider. The Customer Information Quality Specification from OASIS provided the basic structure, but a lot of new material is needed to make it work. The key is to allocate the data to the correct place in a hierarchy of Party Types and to the roles that are “playable” by each type. It is a thought provoking exercise. It also make you well aware of the potential data quality pitfalls of mis-allocating data to a less advantageous entity within the overall data architecture. (Note to readers: this is just the beginning ov some very cool stuff.)

Mentoring, Consulting, or Outsourcing?

What is the difference, if any? I would contend that there are differences. Simple outsourcing occurs when a company or government agency wants something done that it either does not want to do itself, or can get done at less cost from outside. Consultants, on the other hand, are normally hired to do a task cannot be done with in-house resources. As such, they are generally fairly expensive. Usually, consultants are hired to get an outside view, to get objective recommendations, or to do a one-time task that requires special expertise. In such cases they are a good use of resources.

There is a downside however. When a consultant is hired to do perform a repetitive task, and he simply performs that task, again and again, he is no longer a consultant. He has become a high-priced outsource contractor. It is also possible that he makes his contribution indispensable to mission performance. Now he is not only high-priced, but a risk. From an organizational viewpoint, any indispensability is risky. Indispensable consultants or consulting companies are even more so.

So, what do you do when there is a long term task that must be done, but cannot be done with in-house resources. One way to handle the situation is to grow some in-house resources. You can send folks to training. Sometimes, however, training needs follow-up, reinforcement, and a bit of friendly supervision. This kind of activity is known as mentoring. Mentoring can be done in-house if there are sufficient resources. Often, however, in-house mentoring is a one-on-one activity and carries intimation of favoritism because of hierarchical relationships between mentor and protege. For less direct mentoring activity, some large companies have large separate mentoring/training divisions. This works well where tasks an procedures are well-defined and folks simply need non-threatening help to understand their work environment.

So, what about something new? You want to follow a new and exciting way for doing something. You want to adopt a cutting edge technology or methodology. If you can find the right person, a professional mentor might be the right answer. A good mentor is less concerned with his accomplishments than those of the folks he is helping. A good mentor is helpful, but no overly directive. It is actually useful to allow proteges to fail on occasion. The learning is valuable. A mentor never competes with his proteges for favor or glory. His value is in multiplying their capability. It is not in his personal glory.  A mentor has the goal of working himself out of a job, as he makes everyone else more productive. A good mentor does not allow himself to be indispensable in the long term. His goal must be to achieve the exact opposite result.

This goal seems to go against human nature. Maybe that is why really good professional mentors are not easy to find (and why good ones are actually in demand because of their scarcity). In order to avoid the human tendencies that lessen the value of my mentoring activity, I have developed a creed. I try to follow Grandpa’s Creed in all my work with the Virginia DMV and with other consulting clients where mentoring comes into play. In general, I would say it works. I am certainly better for it.

Software and BPR Process Mentoring

I continue to work with the Virginia DMV in support of their Systems Redesign project. It is their process, but I have the great pleasure of helping them decide how they want to approach the many issues that come up every day. The whole thing is based on choosing the best approach to preparing for actual implementation using the Iconix Software Engineering process, but doing so in a way that supports the specific needs of the Virginia DMV. The project is large, and so is the BPR team, so the need for specific requirements traceability is is perhaps more pronounced than it is for typical Iconix implementations, where teams are generally smaller and less diverse in technical and functional background. The DMV has defined an approach. I think that they are on the right track. I look forward to a very busy Spring and Summer helping them make it work.