Agile Lean Product Development

Overview of Lean

I primarily work for a Pharmaceutical Organization which develops and maintains the products for public Health. The company I work for is, Ironwood Pharmaceuticals, which is exceptional in developing products for people suffering in secretion of excessive Uric acid. These products are marketed all over the world and had a fair share of the market across the globe producing better results and helping the people health at the same time.

Pharmaceutical organizations are more towards the regulations that are controlled by the government since it deals with the health of the patients and eventually are valuable to the public. Pharmaceutical companies are bound by rules when development and delivery of the product is involved, the projects are treated more carefully, and any failure would loss in millions. Unlike the Software companies out there, there are some things which are common when it comes to handling the projects.

In a Pharmaceutical company, there are projects which are handled by the Department of IT in implementing new Software-as-a-Service products that are used within for quality management. These S-a-a-S products are developed by the vendor’s who provide the software to the company for use of their service to help manage the quality process and data integrity of the document.

The process of implementing such projects are discussed below;

First, The implementation would be kicked with a meeting with the vendor form who the product is purchased. This meeting is called Sales-to-service meeting where the scope and the project assumptions are discussed.

Assumptions include mostly the following;

· Documentation procedures shall be followed as per the company’s guidelines.

· Storage of the project Documentation shall be in an online repository of the company

· Existing Systems are not affected by this integration and proper Standard operating procedures are followed to maintain the balance of the quality on either of the parties

· Migration activities are determined prior to the system implementation and the actual migration to be taken place before the system is implemented fully and operational within the company

· Adequate Business, IT and Quality resources will be available.

· Hardware qualification will be performed by IT as applicable.

· The system being implemented shall ensure a proper documentation is provided such as User acceptance testing etc.,

· Some Vendors will need to be qualified in parallel with validation, proceeding at risk

The project is carried in many phases; starting with the initiation phase where the project starts by deciding the key factors of the process and what documentation is necessary is determined by the Regulatory and Applicability documentation which provides the score for the system that determined whether it has High, Medium or Low impact. High impact means the system being implemented has a high risk when implemented at the company and will have a severe impact and are to be taken extra care to avoid any risk of losing data. Medium means that the impact will have minimal to less impact on the data. Low risk means there is less to no impact on the data. Based on the score that was observed and the impact it was determined, the project documentation is determined.

At a minimum the following documentation is provided for each project;

· Business Requirements (Low Systems);

· User Requirements (Med – High Systems);

· Regulatory Applicability and Criticality Assessment (RAC) for each system;

· Validation Plan;

· Acceptance of any existing Vendor or Ironwood deliverables;

· IQ/OQ Documentation

· UAT test scripts;

· Validation Release Memo for each system;

· Validation Master Plan Summary Report.

The Second stage involves the Concept phase, at which the documentation required to prepare the implementation is done during this stage. In our company, the initial plan is drafted inorder to have a written documentation on how the proceedings are done as per the project is considered. Once the plan has been drafted, all the proceedings should comply with standard documentation and should not deviate from the plan. Any deviation within the pharmaceutical company will lead to serious penalty which may be considered the data is altered, fabricated or even falsified.

Once the plan has been drafted and finalized, the system shall be in the configuration phase, where the product which was given as S-a-a-S is configured to the needs of the company and then the vendor works on delivering the product as configures. The meeting is set-up withal the stakeholders and the business along with the IT owner and the Validation persons to see that the product is configured as requested. These configurations are matched using the configurations specification to maintain the documentation that the software stays the same through-out its lifecycle as configured and would be a evidence. For formal verification, a configuration verification is created to make sure that all check-out.

All the concerned parties are then asked to sign all the documentation to make sure that the configuration is locked and then the testing is performed on the test environment. This testing is known as the User Acceptance Testing which means that a formal execution of al the workflows, process designed within the software work as intended. This provides a formal testing evidence that the processes work and is good to be ready for the Production.

All these activities are documented towards the end, so a summary report is developed which would detail all the activities performed during the scope of this project and were there any deviations during the period, and if so, where they documented appropriately as determined. This Summary Report will also provide the document names and numbers following the post execution and also details the training services required to ensure that the end users are trained before being able to get access to the system. All of these details accumulate to determine whether the system is ready for Production or any other activities are to be dealt with before the system can be implemented.

Principles Applied

The company I work for right now has limited to none usage of Lean principles. This is because the company is bound to operate in some defined regulations by the government since it is a pharmaceutical company. These regulations add few extra processes for extra patient health. The government feels this as responsibility and will also be helpful while auditing to ensure that the company has stood by the regulations that it was bound to while developing any drug/device.

To begin with, let’s discuss the lean principles that my organization uses on day-to-day basis. One good thing of being bound by regulations help you improve the development process consistently a there is a lot of documentation involved in the process. These documentations help the company when they are paperless and allow e-signatures online, while ours is still not automated and eco-friendly, we use a lot of paper and wet-sign them to make sure that the document has been reviewed and accepted by the concerned parties. However, there is a lot of waste that is being eventually collected in form of paper and this waste is just stored for years for the sake of audit purposes as patient health and safety is involved.

Secondly, the best lean principle that my organization follows is “Quality”. The quality that was built around the company’s development techniques has brought successful compliance results. The quality team are most important while dealing with the compliance techniques that allows the company to be bound by the rules of the quality. Quality decides the process, techniques, implementation, procedure and verification of the documents, all these activities are defined appropriately.

Also, creating knowledge is important aspect where each team is entitled with unique skills which on a whole shall form an efficient interaction to an affluent success in development. Knowledge is most resourceful in the company and helps the development process with new techniques with the knowledge. A team or person shall allow the flow of the knowledge in the company than to keep the teams in divisions and not let them flow the knowledge which will help succession easier. There should be a weekly meeting session that will hold the knowledge session to discuss the difficulties of any task that is rendering the flow of outcomes and all teams can be sat together to discuss the strategies and share knowledge upon the issue to come with any probable outcomes to resolve them.

However, creating commitment is one lean principle that our company is lacking, especially when work is outsourced, no definite process to check the work that was being done or a verification of the process to make sure that accurate procedures are followed. This creates a lack of commitment within the organization. The internal members tend to lean towards the company that was outsourced. Though, the work is outsourced, a minimum verification procedure must be in place and this was lacking which leads to lack of commitment.

Although, lack of commitment is shown by the employee, there is certain respect towards each team member or a team on a whole. This creates mutual respect between the individuals, by creating mutual respect, there is a confidence that grows in between the peers which will allow them trustworthy and this trust will in turn enable work efficient behavior. Mutual respect also allows peers to be more skillful and will allow track of the progress and will allow any member to ask about the status without hesitation and the work shall be transparent.

There is one big asset that our company has is the pro-activeness in delivering the work around. Each employee shall be accountable for the work that is given to him/her. In a pharmaceutical organization, the work is pro-actively done either it be a periodic review, SOPs draft and revision of documents that are already existing. The pro-activeness allows to use structured development and help plan the activities ahead of the year. Once these activities are established, the company divides the goals and objectives to be achieved based on the quarter. The goals and objectives are combined into projects and the projects are divided upon the teams. These teams work around these projects to achieve success and help the company progression into successive revenue.

Apart from all these lean principles, there is one principle that each department follows are the procedural techniques that are implemented in the company and all are bound to follow the procedure. These procedures help define the company and how it manages. These procedural techniques also allow the value stream process. In our organization the procedures are written for all processes that involve in development stages. By developing such procedures, it will help everyone to be aligned with what to be done at a particular time. If the process Is deviated, there is a procedure written to consolidate that as well, where the deviation is taken and a proper written page is submitted explaining why the deviation has occurred and what has been involved in causing the deviation. Essentially root cause is developed. These sort of writtem instructions always allow our organization to maintain a value stream map and help to stay within the proven success graph.

However, our organization as mentioned above should learn to automate some of the procedures that will ensure that some waste is eliminated. Right now, there are no proper waste elimination procedures which is one of the lean principles. By reducing the waste eliminatin there are lot of under relying activities that will be reformed as well such as the reduction of waste in the paper which will reduce the amount of paper used and also the inventory that is brought in everyday for the use of paper shall be reduced which in turn will create possibility of lean procedure implementation.

References:

https://leankit.com/learn/lean/principles-of-lean-development/

Seven Wastes

The concept of wastage was first introduced by the Toyota during early stages of lean manufacturing. These seven wastes are taken as an initiative by the Mary and Tom Poppendieck who translated these wastes “Seven Wastes of Software Development”

The seven wastes are;

1. Partially Done Work

2. Extra Features

3. Re-learning

4. Handoffs

5. Delays

6. Task Switching

7. Defects

As my organization is a pharmaceutical organization, which involves in developing drugs and devices. The software projects that happen in my organization are pretty small as I have mentioned in the earlier sections. The projects that we do is not developing the software development, but the software has already been developed and provided to us for the vendor for day-to-day operations. But I had once worked for a software development project with a contract form my organization, which helped me to see few things up-close but not for too long. However, I saw the following wastes that effect the organization and how it may be handled;

Partially Work Done –

The organization has too many tasks that are assigned to each other at the same time to reduce the amount of burden that has within the employee. For example, as soon as the project sets to the initiative phase, there are number of documents such as planning, smoke test, execution and summary of the results etc. All these activities are tied to each other but the summary is done at a later time. However, these all activities are committed to a single sprint. While a single sprint is going on , there is another sprint that isbeing started and the work is being left undone by the end of the day. As these compilation takes place, there is a lot of work that is not done or partially done and never completed. This was the first thing that developed to failure of our first project.

Extra Features –

The decision of what features to include in the software is done prior to the tasks being assigned and the sprint being started. These are developed into stories by a meeting that was held with all the concerned parties together to come up with the ideas and make them successful. The reason these meetings are held once is that all provide their ideas and there is no going back on the features. However, this was not the case, one of our consultant decided to go-over the manager to include a feature that allows the date to be modified by the user to suit best purposes and add extra feature to change the report schedules based upon the date setting across the world. The standard feature was to allow users with pre-defined reports and a pre-defined date format. But, as these extra features allowed extra stories with a few extra week for a sprint which ttaly disrupted the schedule and made an unnecessary interruptions to meet the deadlines.

Re-learning –

This was the most particular reason why we failed to meet our last sprint cycle eventually delaying and unsuccessful project. There was a feature where the document request approval process to be included within the approval workflow. This was a major tweak because this involves two codes one to which allows the workflow to surpass to a superior if it was not attended in 30 days. The development took several days, and the developer had not included any work notes while performing this function. We encountered the same issue while deploying the production and the tweak was not covered in the PROD installation where the developer had to re-do all the work from the scratch because the notes was not saved. This made the PROD install on a week delay that has affected the business of the stakeholder.

Handoffs –

The project that we were working was a important development as the software is used for adding the audit log files to the server as the SAS folders are not monitored before which lead to the audit observation by the FDA. I was assisting in the project with the contractor. The project was to be completed before the audit observation was submitted to the FDA i.e., within the 90 days of the observation. During this phase the company was also undergoing a merger with a high-profile company that bought the organization. This merger has led to too many complications in between the project and all of a sudden, the team that developed the project and were close to completion are moved to a different project. This led to a serious set of complications where the new team was to be handed off the work with all the knowledge transfer and the work status was discussed in a variety of many meetings. These unnecessary meetings and the handoff had led to the delay and was very hard to meet the tight deadline the company has been impounded with.

Delays –

As mentioned earlier in the Handoffs, the project getting transitioned to a new team is major delay that I had encountered whilst also I have seen that a project pan completely getting altered on half way through the project. However, the transition is the most concerning part in my career. Th transition made the company stall the work that was done by the team. In addition, th team had to put in extra work to get all the updates that were done till date into a presentation or work notes to bring that to the transition meeting held between the new team. These meetings cost the time delays, work delays and moreover, hindering the project furthermore into the date meeting with the deadline.

Defects –

The most important thing that anyone would not want in the project is that the software that has developed has defects. Well, in our case there was this one instance in a project had lot of defects during the first stage of the development. This has happened due to the fact of negligence by the entire tema to cross-check the work that has been done before and this led to multiple defects while reaching the end of the sprint testing. A particular reason was that developer was working on two different projects and had made a mistake on putting the wrong codes. These codes were then sent to the quality who had completely missed these small defects which ultimately led to the demise of the software and the work had to be re-done and this cost the company.

Value Stream Mapping

Value Stream Mapping 2

The pharmaceutical organization is also a place where quality precedes the time taken to get the request completed successfully. However, the time is pertinent at times when the request is tied to a observation by the quality and it helps them get it done sooner the better.

The Survive ticket response time is one process that my organization had for a very long time. This service request is used for many operations within the company/ It is used for software request, hardware request, Configuration change updates, hiring ticket, decommissioning systems and request for change services that handles all the change process for the systems that are implemented with the company. These systems are used for GxP purposes, which means that these are regulated systems which comply with the regulations within the company that are followed as best standard practice.

Right now, the service now ticket implementation is right now implemented in providing service as displayed below;

First, the ticket is created by the user that has any request that he/she has for. Be that specifically a software request to be installed or a hardware accessory that is needed for the person. After the ticket is submitted, based on the category and the need, the ticket is then sent to the manager intended for based on the category. This ticket is approved by the manager which is indeed sent to the support center that works down to get the tickets completed successfully, the ticket processing time takes more than twelve hours and the support center is off-shore which sometimes takes more time than required. Once the request is completed successfully, a notification is sent to the user that had opened the ticket and let them know that the process is completed with no exceptions. The time that takes to complete all the process is around 3 to 4 business days. I feel that the process is very vast and can be reduced to some extent to get the request completed successfully. Three or four day is more that any user could ask when a ticket is of high priority. Though the high priority tickets are completed within a certain limited time to accommodate the needs but the change is inevitable to complete the normal ticketing service as requested and then the emergency tickets are completed more faster.

There are several wastes that I think personally can be identified from this process; Hand-offs and Delays. These are the two details I think that can be reduced from the above process, which makes the service ticket process time more efficient and effective so that the users may find it easy to use and help the service time reduce to get their needs completed successfully as expected. First thing I would recommend is to eliminate the delay issue of sending the ticket to manager first then the support center. The manager approval is redundant where as the request is already sent to the support center and they would verify the confirmation form manager instead. This would save the time of ticket processing by 12 hrs and reduce one day. It would also increase the time that a support person can work on the ticket and get the things going before the approval comes. Second the ticket processing time can be divided into two parts, right now all the tickets go to the support centre no matter what the type and category is, but I feel that the hardware requests go the internal on-site IT department that can handle the request and software push tickets to the support center. Meanwhile the change requests that are helping perform system change implementations are handled by the validation or IT R & D that handle these tickets. By absorbing these integrations into three different departments for three different tickets will not only reduce the amount of time but also increases the completion rate at which the tickets can be implemented.

Document Change Request Process is one more process that is currently used in the quality department,

This process is used for having any document that needs to be uploaded into the system to make sure that the document is followed through a standard operating practice and the reviews and approvals take place in a planned and proposed procedure. This takes place within 2-3days but then this procedure can be reduced to a day if the proper protocol is followed and few steps are eliminated that are waste; one is partially done work and the other is the defects. The system that this procedure is carried out uses a unique feature that it allows the user to initiate the Dcouemnt change request process and then once the process is initiated it is sent for approval within the system to get a DCR Process number and name with also a template that can be used by the user based on the document they chose. This template is the base that should be used for the draft that user can complete the work before sending for review. Sometimes, the user has a template ready before head to send the document for review, but one the system generates a template and turn out to be it is a different template because without a notification the quality has changed the template. This allows a partially work done document to be rendered invaluable and the work time spent ahead is completely irrelevant. One more process is that, the navigation to the system is not very convenient as the users can only get through to the docuemnt approvals via a notification that is received in an e-mail once the DCR Process sis assigned. Reducing the navigation defects will allow the user to reduce some time of the process. Also, reducing the time of drafting by giving the correct template before head by placing the templates in the sharepoint local to the network. The process only requires the document attached to the slot that is provided by the company and not to stress time on the template. These processes can reduce a lot amount of time and help the users. However, the review and approvals in the process work according to the procedure.

Lean Activities

The Lean activities are shown below in a Kanban board, The Kanban board is divided into three categories,

To-Do List – is used for letting the members know what hings are expected to be completed.

In-Progress – is used by members to recognize the work that is in progress

Completed – is used to identify the work that is completed.

Project Implementation Kanban Board is shown below;

Service Ticket Response Time Kanban Board is shown below;

Document Change Request Process Kanban Board is shown below;