Jason Boyd's Weblog tag:www.jandrconsult.com,2006:/blogs/jason//4 2006-02-16T05:27:11Z Movable Type 3.2 Supporting Mission Critical Applications tag:www.jandrconsult.com,2006:/blogs/jason//4.79 2006-02-10T15:38:54Z 2006-02-16T05:27:11Z During the development of a mission critical application, there is a tremendous amount of effort spent on building quality into the application. This effort is justified because once the application is deployed, the amount of downtime or system errors is expected to be minimal. The reality is there will be unexpected application responses or application functions that simply stop working, due to either slightly different data sets or a completely different execution path through the application that the end user has chosen to use. When this occurs the support response to the end user becomes critical to the overall success of the application.... Jason Boyd During the development of a mission critical application, there is a tremendous amount of effort spent on building quality into the application. This effort is justified because once the application is deployed, the amount of downtime or system errors is expected to be minimal. The reality is there will be unexpected application responses or application functions that simply stop working, due to either slightly different data sets or a completely different execution path through the application that the end user has chosen to use. When this occurs the support response to the end user becomes critical to the overall success of the application.

]]> As the software is deployed to multiple customers, each customer will react to experience system failures differently and is likely to have different ideas about what is an acceptable support response. Responding to these different expectations is the challenge of the support team and will be a major influence of the customer’s confidence in the system.

To build or strengthen the confidence in the support team and the application, there are a number of factors that require customer and the support team agreement about the support case process.

Class of support request
Once a support team is established there will be many different types of requests that arrive from the customers. These will generally fall into the categories of inquiry, user error, configuration, and application bugs. It is essential that the customers know that these are the categories that are used to determine the class of the request based on the information provided by the customer.

Issue Criticality
A business impact assessment will need to be performed by the client prior to submitting the request. This provides the support team with the justification for assigning a priority to complete the analysis. It is extremely easy to fall into a habit of the last request delivered receives immediate attention; but, this only creates fragmentation in the support response. By providing an impact assessment to the support team, they are able to ensure that all truly mission critical functions are able to be performed by the application at all times for each client.

Response Time
Based on the class of the request and the criticality of the issue, a response time can be assigned. This does not mean the issue will be solved in this time period, rather the customer will receive status updates on the issue in an interval that is appropriate to the type of request. They will also receive escalation notices that have been pre-defined for the class of the support request based on the elapsed time.

Resolution Responsibility
Once a resolution has been identified and suggested by the support team, a responsible implementation party will be identified. At the time of assignment, the expectations for delivery implementation must be agreed upon given the current work load of the responsible party. This will give the client the opportunity to exchange other requests that might be in the implementation queue in order to prioritize all outstanding items.

Once the framework of the client’s expectations has been defined, the structure of the support team will provide the backbone of support for the clients. This structure must be able to expand and contract with the support load of the current and future clients while continuing to meet the agreed upon support response times.

There are five main categories of roles which construct the support team:

First Responder
This position is the first point of contact with the clients. The position will take support line calls, monitor the support voicemail box, and email box. They will be responsible for generating the case, communicating the class and issue criticality back to the client, and providing the client with a case number for future correspondence. It is critical that this response is sent back to the client as quickly as possible so they know the issue has been received, the severity of the issue, and have a reference for referring to the issue in future correspondence. This will also give the client the ability to agree or dispute the class and criticality of the issue that has been assigned by the support team.

Trainer/Client Communicator
This position is held by an individual who is able to work one on one with client representatives and is able to help them through understanding portions of the system and modifying the configuration of the system to meet their needs. This position requires very strong communication skills and patience with the client to ensure that they are not just understanding the current issue, but are receiving knowledge transfer training that will help them solve future issues without the help of the support team.

Application SME
This position is responsible for understanding the application and all background code of the application. They will be responsible for investigating bugs in the application, and will require access to all available source code and current design specification documents in order to determine the root cause of an unexpected result in the application. They will also be responsible for correctly identifying the failing code and proposing a possible solution to eliminate the problem that was experienced by the client. This information, along with the exact steps to recreate the issue, will be vital to the developer that is assigned to fix the bug in the application.

Developer
This position is responsible for developing and testing the necessary updates to the application that are discovered and confirmed by the support team. Depending on the development load, this position may be shared between application development and support development.

Manager/Case Assigner
This position is responsible for routing the issue to the appropriate group or individual for investigation. This position will be charged with knowing the current workload of the other positions on the support team. Other responsibilities of this position include: daily status reports to each client on all open cases, weekly communication to higher management about the metrics of the support team, aiding in any ongoing investigations, managing any escalation procedures, and working with the application development team to ensure awareness of any ongoing development.

If the support needs are not large, these positions may be implemented as half time positions and could then be shared by a single resource. The key is identifying the role of each position and the vital function to the support team that is met by each position. Through the use of a single point of contact, agreed upon case classifications, agreed upon response times, and appropriate communication to the clients and to the organization management, mission critical support will supplement and enhance the client’s confidence of the system.

]]> Team Direction tag:www.jandrconsult.com,2005:/blogs/jason//4.76 2005-11-02T14:40:50Z 2005-11-02T15:49:44Z Over the past six months or so I have been helping manage a team of resources that is building templates for a SQL*LIMS implementation. When I was discussing this with a member of a training class I was teaching, he asked how we were able to build all of the templates with multiple distributed resources that aligned to a set standard. At the time I could not give him a very good answer. All that I could come up with was that "we just did it." That was a poor answer and I knew it, so I have been pondering it every since.... Jason Boyd Over the past six months or so I have been helping manage a team of resources that is building templates for a SQL*LIMS implementation. When I was discussing this with a member of a training class I was teaching, he asked how we were able to build all of the templates with multiple distributed resources that aligned to a set standard. At the time I could not give him a very good answer. All that I could come up with was that "we just did it." That was a poor answer and I knew it, so I have been pondering it every since.

]]> As I mulled over the history of the project I realized that the process we went through was not specific to building SQL*LIMS templates. The process is applicable to the building of any system with multiple resources concurrently working on individual deliverables that make up the entire project. The following five items made up our process:

Generic Procedure
A procedure was developed that generically described the building process. This procedure gave each member of the team the exact steps that should be performed. Each team member always knew the next step to be completed and therefore could mange their own time and schedule accordingly. A clear path to project completion was outlined so that following the completion of a deliverable each resource knew the next deliverable they were responsible for. For this project we did not assign specific deliverables, but classes of deliverables and allowed each resource to chose their own deliverable from the class they had been assigned.

Alignment to a Standard
A standard was created prior to the project kickoff. This standard was explained during the team training so that each member completely understood how the inputs were used in the final product. Even though each deliverable would be unique, they had to align to the generic standard that was created. This standard could be used by each team member as a sanity check for initial questions about their assignments.

Collaboration Tool
A collaboration tool is essential. This tool allows each team member to remain connected to the development progress of the system and visualize how their deliverables are contributing to the end system. A collaboration tool is also pivotal in remaining agile through the course of development. Through the use of consistent communication techniques and a single repository for all project related materials, each team member can be responsible for remaining connected to the project and standards during the creation of their deliverables. The collaboration tool of choice at J & R is Groove. We used Groove on this project to track the development of the deliverables, which allowed for every member of the team to receive in real-time the progress of the project.

Peer Review
As each deliverable was developed we required a peer review by another member of the team that was performing the same tasks. This process helped the project on many dimensions. First, it allowed us to catch mistakes very early in the process. Second, it naturally created alignment to the standard because any differences were discussed between the developers. Third, it created a community of peer reliance; members of the team would ask questions of each other before involving management. For this project we only required a single person to perform the review due to the type of deliverable. However, for more complicated deliverables or for reviews of written code, this peer review should be expanded to the "team". The scope of this team may vary, but it should consist of as many developers as possible and at least one representative from management.

Elevation Protocols
When peer reviews produced questions without a clear answer provided in the standard or when a unique situation was required by a certain deliverable, the development team would raise the concern to management. These questions were created in the collaboration tool so that other members of the team or management could post responses that were visible to the entire team. This created an additional place for developers to look for answers and allowed for the question to only be answered once.

Through the implementation and fine-tuning of these processes, we were able to create many deliverables that aligned to the customer’s expected quality of the deliverables. As we move on to future projects we will continue to modify each of the procedures to gain the highest efficiency; but, the goal of each processes will remain the same.

]]> Software Quality Assurance tag:www.jandrconsult.com,2005:/blogs/jason//4.74 2005-10-22T03:50:29Z 2005-10-24T14:28:45Z The concept of quality has received a lot of coverage in the insight columns on this site, and I do not want to re-examine the timeless question of the origin of quality. Instead, I would like to concentrate on quality assurance. In the manufacturing industry, quality assurance is what drives the release of products and production benchmarks. The ability to produce X products with only Y defects is how production cycles are measured to ensure that they achieve the goal of maximum efficiency and profit. In manufacturing, the measurement of quality is determined by a set of tests which compare the recently created product to the accepted example or standard for the product. For creating software, the idea of quality assurance differs slightly because you are not replicating an already created product but instead creating a system based on already defined specifications.... Jason Boyd The concept of quality has received a lot of coverage in the insight columns on this site, and I do not want to re-examine the timeless question of the origin of quality. Instead, I would like to concentrate on quality assurance. In the manufacturing industry, quality assurance is what drives the release of products and production benchmarks. The ability to produce X products with only Y defects is how production cycles are measured to ensure that they achieve the goal of maximum efficiency and profit. In manufacturing, the measurement of quality is determined by a set of tests which compare the recently created product to the accepted example or standard for the product. For creating software, the idea of quality assurance differs slightly because you are not replicating an already created product but instead creating a system based on already defined specifications.

]]> I like the definition for Software Quality Assurance the I found on InfoBeagle.com, it states "Quality assurance is defined as a set of procedures designed to ensure that quality standards and processes are adhered to, and that the final product meets or exceeds the required technical and performance requirements. Quality assurance is a widely used approach in the software industry to improve upon product delivery and the meeting of customer requirements and expectations."

So, if software quality assurance is defined as meeting or exceeding the required technical and performance requirements, then the process of creating these requirements is the root where all quality is derived for software. Sure there are quality processes that are put in place during development which add quality to the end software product, but these are designed to meet the originally defined customer specifications.

The input used to create user requirements must be considered very carefully and the correct people must be involved in the process of gathering these requirements to ensure the end system meets each need of the business process. Business process mapping must be done first and then assigned to functions of the system to ensure that each business process is accounted for in the final user requirements. If business mapping is left to be an implementation step, then no amount of adherence to requirements will help the end users perform their business process tasks with the new system.

A common mistake to make while deploying software, especially software like a global LIMS system, is that the new system should replicate all functions of the current electronic or paper system. This is the wrong approach to gathering user requirements. Instead, the complete business process must be determined and written down as the very first step prior to determining all of the steps that must be executed to perform each business process. This top down approach will allow for the end users to avoid missing any key steps in their process that should be met with the new system.

Once the user requirements are determined, the functional requirements can be written by the design team. Beyond producing the functional requirements that will drive the development cycle, the design team should provide a written document in end user level language of exactly how the new system will address each of the high level business processes. This will allow the user community to review and accept the approach defined by the design team to meet their required business practices. This approach should minimize the number of 11th hour design updates to meet go-live requirements and remove the difficult task of fitting a known business process into a developed system. With this approach to forming system requirements, end users take responsibility for how they will be using the system and hopefully remove any surprises of lack of functionality.

]]> My Stop-doing List tag:www.jandrconsult.com,2005:/blogs/jason//4.73 2005-10-13T14:17:37Z 2005-10-15T19:09:54Z I have been back to work for almost two weeks now following a 2 week holiday. I usually take one long holiday a year because it offers me an opportunity to fully detach from my every day life and perform an intense audit of my day-to-day decisions. Normally, this time is completely devoted to my personal life, but this year I choose to concentrate entirely on my work life. This was mostly because I was having difficultly separating my work life from my personal life.... Jason Boyd I have been back to work for almost two weeks now following a 2 week holiday. I usually take one long holiday a year because it offers me an opportunity to fully detach from my every day life and perform an intense audit of my day-to-day decisions. Normally, this time is completely devoted to my personal life, but this year I choose to concentrate entirely on my work life. This was mostly because I was having difficultly separating my work life from my personal life.

]]> Driven by the J & R mission statement and my general desire to make our customers happy, I continually try to exceed the expectations of our current clients. This is a goal that I have had since beginning my career and believe in very strongly. Lately, this desire has produced a heavy workload and some stressful days but success has always been achieved. The problem is that I have sacrificed working on many of the other tasks (including blogging) that when asked I would say are equally important. These other tasks are easy to push off because they usually do not come with customer expectations; they are my own personal development goals. By delaying working on these tasks, my actions indicate that the personal development tasks are actually less important then the new tasks that I commit to for our current customers. I believe that in some instances this should be the decision, the problem is that I have consistently made that decision for the last 5 months.

So what if there were 2 of me? With one of me devoting 18 hours a day to exceeding each new customer deliverable and expectation, the other me would be able to concentrate on personal and business development. I believe that even if I was able to create two of me I do not have the ability to implement this simple solution. What I realized on holiday is not that I need more available time, but that I need to be more devoted to all the tasks that I believe are important - not just those that come with customer deadlines. This requires task prioritization in addition to realistic communication to my customers about my ability to meet task deadlines. This should allow my customers to evaluate if they are willing to wait for the deadline that I propose or to find another resource to complete the task (this last part is what kills me).

This line of thinking is not new, I have been trying to operate like this over the past year but have been unsuccessful. Usually when I get fired up about this I create a list of my current tasks and prioritize them with deadlines. This will work for a while but the problem is that I have not fixed how tasks arrive on my to-do list. While on holiday I read Good to Great by Jim Collins, this is an excellent book that I highly recommend. One small point that he makes in his book is the importance of a stop-doing list. I found this simple point to be very enlightening; to have a stop-doing list that each new task or goal should be evaluated against prior to making it on to the to-do list. To that end here is my beginning attempts at my stop-doing list.

1. Stop overbooking my personal development time with new tasks.
2. Stop committing to unrealistic task deadlines.
3. Stop saying "yes" just because I feel that I should say "yes". Neither the client or myself win in this situation.

This marks the end of my scheduled personal development time, I have to get back to work.

]]> The Not So Quick Fix tag:www.jandrconsult.com,2005:/blogs/jason//4.61 2005-06-11T17:31:03Z 2005-09-25T18:12:21Z Jason Boyd We have all been at a place in the application life cycle where we encounter a problem in the application that creates an unexpected result.  Sometimes there is a work around, other times the application must be patched.  Patching an application should always be addressed carefully and approached with the utmost care.  This opinion was recently strengthened in a recent (and ongoing) experience I am having with my lawn.  Seriously, I'm not joking.

]]> How I patched my lawn is also an example of a software patch.  The bug is encountered, a solution is designed and tested that addresses the problem, and the solution is implemented.  Usually the individual responsible for designing the patch must take it upon himself to ensure that the patched code will not impact any of the other functions of the system.  This can be a difficult task to accomplish depending on the designer’s history with the application, availability of dependency documentation, and complexity of the system.  Within database applications the design difficulty is also heightened to include designing the patch to appropriately respond to all available environment or data configurations.  This responsibility should not be taken lightly nor assigned randomly because the results of a hasty patch could develop long lasting issues.

Back to my lawn.  After I patched my lawn I followed the watering instructions from the sod cutter and my new sod pieces began to grow in nicely.  A few weeks went by and I noticed that my new sod, and the lawn around the new sod, was starting to brown.  I began to become concerned so I enlisted the advice of a few of my neighbors.  I am relatively new to Florida, and since I have been here I have really only been maintaining my lawn, not troubleshooting it.  I carefully explained the history of my actions and asked each one for their advice.  Their responses varied greatly: too much water, too little water, contaminated water supply, and encounter with deadly chemicals.  Attempting to not spend any more money then I had to, I slowly tried each of the different advised remedies.  Meanwhile my lawn was continuing to deteriorate.

The software parallel here is that following a patch, the system may appear to work correctly. However, over time the underlying effect of a poorly designed software update will produce unexplainable failures in the application.  From there, the path forward is either to continue using the same approach to fix each of the problems that arise, or to step back and re-evaluate the entire application in light of all of the modifications.

Eventually this is what I did for my lawn.  I came to realize that I was incapable of fixing my lawn on my own, or with the help of my neighbors, and therefore I called a professional out to evaluate my situation and provide a path forward.  After a 10 minute conversation it was determined that my newly applied sod had contained a fungus which then spread to the rest of my lawn.  They applied an appropriate treatment to the lawn and my grass stopped deteriorating.  Unfortunately this effort only saved my backyard, my front yard was beyond repair and will need to be completely replaced.


]]> Independent Test Driven Development tag:www.jandrconsult.com,2005:/blogs/jason//4.55 2005-05-20T04:52:35Z 2005-09-25T18:12:21Z There are quite a few development styles that exist in the area of software development. One of these is labeled "Extreme Programming". Besides having an edgy name, this style of development suggests many outside the box ideas for improving both the quality and speed of delivery for developing systems. Personally I'm a little skeptical of some of the methods, but one concept that does intrigue me is test driven development within a pair programming environment.... Jason Boyd There are quite a few development styles that exist in the area of software development. One of these is labeled "Extreme Programming". Besides having an edgy name, this style of development suggests many outside the box ideas for improving both the quality and speed of delivery for developing systems. Personally I'm a little skeptical of some of the methods, but one concept that does intrigue me is test driven development within a pair programming environment.

]]> Personally I'm not the biggest fan of pair programming. I really don't like the idea of someone looking over my shoulder arguing with me about tabulation in my code. However, I do like the concept of pair development. The major difference between these two is found in execution. During pair development one person functions as the author of the code while both people participate in each design cycle. The team meets together to design the next cycle for the code and then the author works independently implementing the agreed upon design. This approach creates blocks of time that the non-author can spend creating tests for the developing code.

What intrigues me about this approach is that the developed test scripts are created based upon the design - not based strictly on the actual code. In concept, Unit Tests should be designed to test the inputs and outputs of each block of code. All to often the code author has certain pre-conceived ideas about the permutations of the environment and data that can be sent through each code block. If the test script author is the same as the code author, these pre-conceived ideas also drive the test script that is created and can lead to bugs not being discovered until the Integration Testing phase. If the test script is authored by an alternate person then the code author, the code benefits from being tested from an independent source. This independent source will be primarily concerned about the functional responsibility of the code and less concerned about how to test every functional block.

During a recent development effort, the schedule for delivery actually forced us to use this concept for a code maintenance release. For this effort I was the code author and I was quite concerned about developing code without developing the test script in parallel. I found that I was quite uncomfortable without the "guess and check" process I was familiar with. However what actually transpired is that I spent more effort on ensuring the quality of my code due to the risk of embarrassment when my code was evaluated. Additionally, the developed test script determined additional modifications necessary in the code that I would have not conceived of due to my perspective of the functionality.

I don't feel this experiment proves the validity of the approach, but I do believe that it provides incentive for a purposeful implementation in the future.

]]> Decisions and Opinions tag:www.jandrconsult.com,2005:/blogs/jason//4.50 2005-05-14T13:58:36Z 2005-09-25T18:12:21Z I love working at J & R. There are a lot of reasons why I feel that way, but one of the top reasons is due to the balance of opinions and decision making. This may seem like an odd balance pairing but it is vital to our company's success.... Jason Boyd I love working at J & R. There are a lot of reasons why I feel that way, but one of the top reasons is due to the balance of opinions and decision making. This may seem like an odd balance pairing but it is vital to our company's success.

]]> As a company we are often faced with decisions, either about the direction of the company, design decisions for complicated deliverables, hiring additional personnel, where to go for lunch, etc. Rarely is there a shortage of opinions. The reason why I know this is because they are often shared, even when not solicited. This may seem like I am picking on my co-workers but in reality I am celebrating them. The ability to express one's own opinion, and have it be appreciated by others, is part of our vision here at J & R.

The problem with opinions is that they are relative to a person's experience and are partial to their preferences. More importantly, they are not decisions, they are only streams of consciousness about a decision. This problem is great when sitting around drinking wine with your buddies, debating if a suit made from duct tape is really comfortable enough and appropriate to wear to a wedding. This problem is disastrous when your project is running late and the timeline is moving backwards instead of forwards.

When a project task is defined, a single person must be identified as the decision maker. This does not mean that the decision needs to be made by that person alone; a team approach to decision making will often result in a better decision. However, if the team is put in charge of making a decision, a lack of ownership develops. This team needs an assigned leader to drive the process and be responsible for the presented decision.

With the responsibility of a decision resting on the shoulders of one individual, it is important to choose that person wisely. This position needs to be filled by an individual who has the respect of the rest of a team. If the resulting decision is not respected by the rest of the team, nothing is gained. Additionally, this individual must have the personality to guide the decision making process without offending the individuals who contribute opinions. An individual who always does what they want to do is best left making decisions only for themselves.

This brings me back to the decisions at J & R. The common practice here is to listen to everyone's opinion, and then a specified individual makes a decision. I have always respected the decision made even it was are not in line with my opinion because I know that my opinion was heard and seriously considered by the decision maker. This is important because it means that I am a satisfied employee and the company has continued to move forward even when I was trying to pull it back.

]]> The Contingency Plan tag:www.jandrconsult.com,2005:/blogs/jason//4.40 2005-04-15T02:39:04Z 2005-09-25T18:12:21Z In my opinion, one of the most overlooked line items in a Project Plan is related to contingency. Dictionary.com's definition of contingency is "An event that may occur but that is not likely or intended; a possibility." Or "A possibility that must be prepared for; a future emergency". Every good project manager allocates a certain amount of time and associates it as "contingency". However the actual plan for the contingency is usually left until the "future emergency" is the present emergency.... Jason Boyd In my opinion, one of the most overlooked line items in a Project Plan is related to contingency. Dictionary.com's definition of contingency is "An event that may occur but that is not likely or intended; a possibility." Or "A possibility that must be prepared for; a future emergency". Every good project manager allocates a certain amount of time and associates it as "contingency". However the actual plan for the contingency is usually left until the "future emergency" is the present emergency.

]]> A project could have any number of possible contingencies and could be grouped into categories of financial resources, team members, schedule, and technology. During the course of a project lifecycle, there may be any number of little contingencies or there may be one major contingency in one or multiples of these categories. Often these are defined in the Project Definition as Risks and assigned a level of Low, Middle, or High. Prior to beginning any project, all high level contingencies should have a clearly defined resolution plan that is agreed upon by all project stakeholders. This plan may need to be slightly modified during resolution plan execution due to specific details of the contingency; however, the basic path should remain unchanged.

Last week my wife gave birth to our first child. Without going into all of the details our daughter was born via emergency C-Section. My wife's labor continued to a certain point where it was determined that even if she continued on the same path, performing the same steps for a longer period of time, the birth would still be unsuccessful. Prior to going into labor, my wife and I had discussed the possibility of needing a C-Section and a plan was developed with the doctor which included the possible circumstances that would lead to this decision. When the decision was made in the middle of my wife's delivery, the hospital impressed me with their ability to respond to the present situation and move into action quickly enough to deliver our baby within a 1/2 hour of our decision to initiate the process.

What I learned from the experience is that a contingency plan is not complete if all it contains is an additional percentage of time based on the total hours attributed to the project and a feeling of "We'll just handle whatever comes up". A Contingency Plan requires an agreed upon initiation point and known resource requirements.

Agreed upon initiation point:
As the project progresses it will attempt to stay on the designed path established by the Project Plan. At times it will be ahead of schedule and at other times it will be behind schedule. A Contingency Plan needs to be flexible enough to be applicable for project kick off through the delivery date. This means that there is an agreed upon threshold of volatility to the project schedule, but if the project slips behind, based on the proximity to the delivery date, then the Contingency Plan will need to be initiated.

Known resource requirements:
Projects require resources: these may be in the form of budget dollars, available team members, skill level of available team members, rent of operating location, etc. These factors are considered in the creation of the Project Plan and they should also be detailed in the Contingency Plan. It cannot be assumed that during the execution of a Contingency Plan, the resource requirements will be the same as they were during normal project operation. If a Contingency Plan is correctly detailed, then the project will have a higher chance of success even if a major contingency occurs.

If each High Risk is properly identified, and a Contingency Plan is drafted with an agreed upon initiation point and resource requirements, then the project will have a higher chance of successful completion and you will never be quoted as saying "There is no plan B".

]]> Maintaining Quality tag:www.jandrconsult.com,2005:/blogs/jason//4.35 2005-03-31T15:07:11Z 2005-09-25T18:12:21Z Although rarely admitted quality is most often not the highest priority during application development. If it was then the project would have an un-restricted budget and the application "would be ready when it's ready".... Jason Boyd Although rarely admitted quality is most often not the highest priority during application development. If it was then the project would have an un-restricted budget and the application "would be ready when it's ready".

]]> As described for us by Brian in The Delicate Balance, every project must balance the requirements of cost, schedule and quality. He explained that these three attributes of a project should be prioritized and adhered to throughout the lifecycle of the project.

Although rarely admitted quality is most often not the highest priority during application development. If it was then the project would have an un-restricted budget and the application "would be ready when it was ready". This does not mean that quality is not important to a project. The project should be of the highest quality given the constraints of the budget and delivery schedule. If I have $20K to spend on a new car I'm not buying a brand new BMW, I'm shopping at the VW dealership.

This understanding requires project management to consistently build the highest quality into the deliverable - without exceeding the budget or the delivery date. This can be difficult based on situations that develop during the project lifecycle. Unexpected technology restraints, design failures, team member availability, and errors during Integration Testing are examples of situations that will impact estimates of time and resource requirements. Depending on the ability to acquire more financial resources and the luxury of additional time, these events may cause project management to lower the amount of quality that is achievable for a project deliverable.

Given this possibility, on every project it is imperative to structure the project life cycle to not have an obvious shift away from quality. Depending on if cost or schedule is the driving priority, the project must be driven with a level of quality to meet the restrictions of the true highest priority without sacrificing quality when delays occur in the project.

Consequences of disregarding this reality cause the injection of additional risk into a project. It is possible to emphasize too much quality at the beginning of the project and therefore be unable to deliver the application due to the end of available resources. Inversely, the quality of the project may be diminished to a point that delivery is achieved but the product is unusable.

Obviously both of these scenarios must be avoided. The best way to avoid these issues near the end of the project lifecycle is to agree on the level of quality that will be maintained throughout the project. This level can then be built into the project estimates to ensure the needed resources have been allocated to the project. It is imperative to also build this level of quality into issue resolutions that cause unexpected delays. Of the three attributes, quality is the most illusive to quantify and therefore is the most susceptible to be diminished during the final stages of the project lifecycle. Consequently the best way to avoid diminishing quality of the product is to agree on a quantifiable approach to quality during project estimation. This approach can then be applied to each deliverable item and risk assessment and hopefully help the project avoid the loss of quality in the final weeks prior to delivery.

]]> Keeping your Eye on the Ball tag:www.jandrconsult.com,2005:/blogs/jason//4.32 2005-03-25T12:37:14Z 2005-09-25T18:12:21Z In a large scale development project it is easy to become focused on meeting the Functional Requirements and lose sight of the purpose of these requirements. The Design cycle keeps in focus the ability for the end users to use the application after it is delivered.... Jason Boyd In a large scale development project it is easy to become focused on meeting the Functional Requirements and lose sight of the purpose of these requirements. The Design cycle keeps in focus the ability for the end users to use the application after it is delivered.

]]> In college, one of the classes I enjoyed the most was on User Interfaces. What intrigued me about this class was not really what you would expect. I did enjoy learning about color schemes, use of sound, and creating useable widgets, but what I really enjoyed about the class was the focus on the end user. Following the completion of the class I had a new perspective on each piece of software that I built. I would like to think that the User Interfaces I build are more universally acceptable, but what I really concentrate on is creating software that meets the objectives of my end users but also meets them in a way that makes it simple for the end users to meet their end objectives.

In a large development project, often the development team does not consist of any end users. The end users are often consulted during the writing of the User Requirements and requested to sign the Functional Requirements, but they are not often spoken with again about the details of the application until they arrive in a training class. Overall, I do not consider this a flaw in the development process because on large global scale development projects, the less conversation with end users during development the more likely the project will be delivered on time. This is the reason why the User Requirements and Functional Requirements should be agreed upon and signed off on prior to development.

The one side effect of this process is that it is easy for the development team to be more concerned about delivering the project, then about ensuring that the application is useable by the end users when it is delivered. One of the aspects of my job that I really enjoy is conducting training classes. The reason why I enjoy this so much is because of the opportunity to interact with the end users who are actually using the application I helped develop. These sessions can be extremely enlightening because they tend to point out alternate ways that User Requirements could have been met. Furthermore, these sessions tend to highlight the inadequacies of the documentation that has been prepared for the end user.

There is a lot of documentation developed for a large-scale application. Most of it is very important, but only certain documentation is important to certain people. From a technology consultant view, I find that the most important documentation for me when I need to maintain or support a system is the Design Specification. This is my blue print of the system and is vital for me to be able to understand the inter-workings of the application. Unfortunately this documentation is mostly useless for the end user because it was not written in language designed for the end user.

I believe that the most important documentation for a successful implementation is the User Manual. A properly written User Manual will enable an end user with applicable examples, definitions, and workflow charts that explain exactly how they can use the application to meet their objectives. This is especially vital when a new application is replacing existing technology. The end users are accustom to performing certain steps in the existing application to successfully complete their responsibilities. The new application should not force them into a mode of self discover” to perform these same responsibilities.

The second area that is often neglected during the release of a new application is pre-go-live support. Following a training class, the end users are charged with learning the system before it will replace their existing system to minimize down time and confusion. Undoubtedly, the end users will need support during this time. A high quality User Manual should help in this area, but it will not be possible to meet all of the questions encountered through the course of learning the system. This initial exposure time to the application is when the end user forms their opinion of the application. A member of the design team must be assigned to helping the end user community through this transition time. They should have the ability to answer questions from an end user perspective as well as dedicate the time to giving timely responses. Like all first impressions, this pre-go-live time is essential in the forming of the system impression for end users.

Meeting functional requirements is obviously an objective in any development project. Staying focused on the goal of meeting these objectives while concentrating on enabling end users to succeed at using the application should be the primary objective.

]]> Removing the "Personal" from Personal Experience tag:www.jandrconsult.com,2005:/blogs/jason//4.24 2005-03-14T04:29:44Z 2005-09-25T18:12:20Z Creating a mechanism to share personal experiences will create an invaluable tool that will benefit each member of your current and future team.... Jason Boyd Creating a mechanism to share personal experiences will create an invaluable tool that will benefit each member of your current and future team.

]]> The aspect of my job that I enjoy the most is troubleshooting. Every project and every deployment will have something that needs troubleshooting eventually and I always try to be the first one in line for the job. Functional design, developing, training are all areas of my job that I enjoy - but troubleshooting is easily at the top of the list.

During the course of this week I began to really ponder what it is about troubleshooting issues that is so appealing to me. I've come to the conclusion that for me, there are two rewards for tracking down an issue. First is the aspect of meeting a need, secondly and most importantly is the experience that I have gained in the process. This experience is one of the most valuable tools that I have for solving the next issue that is sent to my queue.

The problem with experience is that it is limited to the involved individuals. This is an obvious statement, but the inverse should also be considered. Each member of a team is limited by their own experience when it comes to problem solving. This limitation is most apparent during troubleshooting in a high stress situation.

What if you were not limited by your own experience? When working on a team, it is possible to discuss the issue you are troubleshooting with team members to try and utilize their experience but this requires explaining all of the circumstances, and listing failed attempts. This process could be lengthy and occupies each resource pulled in to consult on the issue.

Alternate solutions include developing a knowledge base, and creating how to documents. These solutions provide some level of disseminating information; however they can often be to formal or problem specific to be useful with troubleshooting an issue that has not yet been encountered.

What I would like to propose is the compilation of personal experience on a regular basis by all team members actively involved on a project. This process should be frequent enough that most experiences gained are captured, but not so frequently that it taxes the timeline of the project. These entries may include items such as the following:

· Anything new learned in the development process while developing a solution to a functional requirement.
· A discovered feature in an application used by all team members.
· A particular system reaction based upon a repeatable series of events. Sometimes just knowing that someone else has encountered the same system reaction can help with the beginning of the investigation.
· How a problem was discovered and solved. Not necessarily what the problem was and what the solution was, but what was the discovery path. This will allow problems that are similar and not identical to still be built from the same experience.
· Diagnostic steps that the developer uses to troubleshoot the code they are developing during development.
· All useful knowledge sources that were used for development or during troubleshooting.

As this information is slowly gathered, members of the team will begin to check this growing repository of experience before they search out a solution for their current problem. This will enable the team to benefit from the gained experience of the group and provide new members of the team with an additional resource beyond the existing formal documentation.

]]> The Danger of Scope Creep tag:www.jandrconsult.com,2005:/blogs/jason//4.22 2005-03-05T16:34:57Z 2005-09-25T18:12:20Z The ability of a project to remain on time and within budget is linked to how well change in scope is managed and communicated between the design and validation teams.... Jason Boyd The ability of a project to remain on time and within budget is linked to how well change in scope is managed and communicated between the design and validation teams.

]]> The software design cycle usually begins with a User Requirements phase, which is used to generate the Functional Requirements of the system. These Functional Requirements are then used by the development team as a basis for the design and development of the system. Traditionally, these Functional Requirements are used to create a Project Plan which determines the timeline and amount of resources required to develop the system.

In LIMS projects, the Project Plan also contains the amount of time and resources that will be required to fully validate the developed system. The development team and the validation team work independently of each other in order to ensure that the developed system meets the agreed upon Functional Requirements.

During development it is not uncommon to uncover additional features that would enhance the system beyond the listed Functional Requirements. This discovery is the beginning of the slippery slope of scope creep. Scope creep usually begins with a member of the development team uttering the words similar to "Wouldn't it be cool if…." followed by the grandiose idea. This new feature may very well be a great addition to the product that is being developed or it may not, this is not important. The vital concern at this point is what is the cost of the addition? When the developer brings up the idea to the project manager it will usually be presented with the total development time requirement to add the feature to the product. There is usually no concern about the amount of additional time that will be required for system acceptance testing and validation.

The Functional Requirements should not be viewed as an unchangeable list of objectives. The natural course of a project will produce additions and exclusions to this list of objectives. However in order to avoid unnecessary delays in the project, it is vital for the design team to communicate any agree upon changes. to the list of the Functional Requirements, and to enlist the help of the validation team in determining the impact of any added features to the timeline and resource requirements to complete validation of the system. The ability for the project to remain on time and within budget will depend on the ability of the Project Manager to control Scope Creep.

]]> Team Code Review tag:www.jandrconsult.com,2005:/blogs/jason//4.16 2005-02-25T03:26:11Z 2005-09-25T18:12:20Z A structured presentation of each line of code is worth the time cost because each member of the development team benefits from each line of written code.... Jason Boyd A structured presentation of each line of code is worth the time cost because each member of the development team benefits from each line of written code.

]]> Last week I discussed the virtue of designing a complicated system through team effort. This week I would to comment on the value of reviewing written code as a team.

Peer review has long been a highlighted event in software development as a method to increase quality and catch bugs as early as possible in the software design cycle. Often peer review is conducted by one other colleague and may be performed without direct interaction with the code author. The peer review may generate questions and dialogue between the author and reviewer, however this tends to be minimal unless there are major coding problems.

I would like to propose that instead of a peer reviewing the code, the code author be charged with presenting the code that was authored. This does not need to be a full power point presentation, but should involve bringing the entire team together and looking at every line of code. I believe that the following benefits will be achieved with this code presentation.

Increased adherence to coding standards:
Often developers believe that they work in a bubble, where the only thing that matters is that the code they produce works. This is after all the primary objective, so less importance is placed on readability, proper structure, commenting, and use of naming conventions. If they are aware that once they have completed their assignment they are going to be asked to present their code to a room of their peers, chances are they will pay a little more attention to the little things that make code maintenance a lot less frustrating.

Increased quality:
During the informal presentation of the code the developer will have the opportunity to explain all decisions that were made, and justify them against questions from the floor. These question and answer sessions may result in a tighter design, or may highlight logic faults or bugs in the software. Often someone in the group will think of a scenario that was not considered by the code author. This scenario can be discussed as a group in terms of the written code, and if necessary a proposed solution can be presented (think Team Design).

Team Skill Level Increase:
While attending the code presentation each member of the team is able to learn how others solve design challenges. These solutions may be extremely helpful to members of the team as they work on their own assignments. Possible private sub-routines written for one program may be used wholly or in part by a different developer. With this increased exposure, code authoring techniques and existing code can be leveraged to increase the skill level of the entire development team.

Presentation Skills:
Public speaking is not usually at the top of desired requirements in a job description. This is not uncommon in any industry, however I think that software developers are even less of a "people person" then the average field. Most developers are extremely proud of the code that they write. Giving them the ability to present this code should increase their comfort level within the group and provide each member of the team the self-confidence to present their ideas in other areas.

Public acknowledgement:
A proper run Team Code Review should never end without any required modifications to the code. This should be the goal of every presenter however the reality is that perfect code is rarely achieved with the first draft. That being said, well-written code is easy to distinguish from code that should be started over again. A Team Code Review is an excellent opportunity to acknowledgement the presenter for a job well done when it is deserved.

]]> Team Design tag:www.jandrconsult.com,2005:/blogs/jason//4.13 2005-02-18T03:24:26Z 2005-09-25T18:12:20Z Complicated user requirements require team input to produce a solid system design.... Jason Boyd Complicated user requirements require team input to produce a solid system design.

]]> Depending on project size and component interaction, developers can often be left to design the entire individual components or subsystems. This decision provides the developer with the freedom to meet the user requirement in the most efficient and elegant design possible. This approach works wonderfully for smaller sub systems or components; however, with more complicated requirements, the more design input the better.

During a recent development project, I was fortunate to be able to work on the design and development of a portion of a system while other sections of the system were being constructed by other team members. Frequently, through the course of my development I became concerned about how the inputs, outputs, and assumptions that I was building into my subsystem would impact the interactions of my section of the system with the others being concurrently developed.

The high level design of the system that we were working with was not detailed enough to answer all of my questions so I began to communicate with my team members individually in order to increase the cohesiveness of the entire system.

Shortly after beginning these conversations it became apparent that the entire team needed to come together to discuss how individual design decisions could and would impact the functionality of the entire system. Therefore we began to meet regularly to define and re-define the overall design of the system.

Frankly these meetings were torturous at times, mostly because getting our heads around the complexity of the system we were designing took quite a bit of effort. This effort however produced an extremely solid design, which drew from all of our creative inputs and unique perspectives on the proper ways to meet the user requirements.

The following benefits were reaped from our team design meetings:

Collaborative problem solving
When a team member would reach a point of uncertainly with the development of a subsystem the team collaborated on the solution. This allowed for the solution to be conceived in an environment that drew from an in-depth understanding of all currently developed subsystems thereby avoiding any negative subsystem interactions.

Detailed impact assessment
When a subsystem redesign was necessary, due to system limitations, all members of the team were able to provide input on the impact of this change to their individual subsystems. This decreased the amount of negative impact across the system and allowed for the developers to modify their subsystems to accommodate the changes concurrently with the code change development.

Code Reuse
The design of the entire system was considered for each redesign of a subsystem. This allowed for rapid logic error detection as well as efficient use of individual subsystems. By clearly defining the purpose and being involved in the design of each subsystem, each team was able to effectively modularize their code for maximum reuse.

]]> Proper Timing to Develop a Support Team tag:www.jandrconsult.com,2005:/blogs/jason//4.12 2005-02-11T01:09:49Z 2005-09-25T18:12:20Z With every mission critical application there is usually a Support Model developed to keep the application running as smoothly as possible. The problem is that usually this Support Model is not formed until late in the development project, if not after deployment. In my experience the proper time to develop the Support Model and staff the team is during System Acceptance Testing.... Jason Boyd With every mission critical application there is usually a Support Model developed to keep the application running as smoothly as possible. The problem is that usually this Support Model is not formed until late in the development project, if not after deployment. In my experience the proper time to develop the Support Model and staff the team is during System Acceptance Testing.

]]> Here at J & R Consulting we utilize a collaboration tool called Groove. Over the years, this tool has become essential in our ability to operate effectively as a team. While I could spend a great deal of time describing the benefits we as a team enjoy by using Groove, what I would like to describe is the impact of losing my Groove client.

Last week my Groove client began to experience difficulty maintaining communication between myself and the other members of my team. At first this situation was only a slight annoyance because I felt disconnected from the rest of my team. However as the hours passed away I began to become increasingly irritated by the lack of team communication, and updates to individual files that I was collaborating on. In short, I was without my ability to function properly as a team member.

While attempting to regain communication with my Groove client I realized that I was without a Support Team that could help me restore my connectivity. While this was a minor aggravation for me, if I were a company that relied on a single application for a primary business function, my situation would be completely unacceptable. With every mission critical application there is usually a Support Model developed to keep the application running as smoothly as possible. The problem is that usually this Support Model is not formed until late in the development project, if not after deployment. In my experience the proper time to develop the Support Model and staff the team is during System Acceptance Testing.

The System Acceptance Testing phase of a Project is an excellent opportunity to instruct members of the team on every facet of how the application works. Team members can take this time to work through some of the same initial issues that new users in the end user community will experience. This experience will be invaluable when it comes time to answer the list of “how to” questions that will initially make up the bulk of questions asked following the rollout.

In addition to learning how to operate the Application, the Support Team must embark on an aggressive knowledge transfer campaign in order to ensure that they are properly equipped to support the application following the release by the development team. This will include understanding the process flow of the application and learning how to diagnose a problem. The Support team cannot be expected to know every line of the code, but they can be expected to know the process tree that is used by the code to perform all functions of the application. The support team should be encouraged to dissect the produced Design Documentation that represents the “as built” system. They must be able to understand the terminology and be able to follow the layout of the document. This will enable the team to reference sections of the system during an investigation. Performing these steps during the System Acceptance phase guarantees the members of the support team the ability to interact with the development team at a level that will ensure their ability to properly support the mission critical system.

]]>