Software Transition Plan

Building a system is one thing and turning it over to production for the end users to reap it's utility is a totally different beast. Transitioning products to production involves training, documentation, support knowledge transfer, operational procedures, production readiness and end of life disposal. It is a complex process and requires good governance and leadership. A well known systems hueristic emphasizes that systems are least stable when transitioning from one governance mode to another.


Each of the areas above could require a detailed plan or set of checklists to ensure all needed actions have been considered. In this post we will focus on software products, and list below key items that should be included in a transition plan.


Training should cover all required functions by the end user, and should include special cases. emphasis should be on how to process business rules, verify transactions, run reports and review output. common artifacts used are handouts, videos, training web pages, online webinars, in person train the trainer sessions.


Documentation includes defect logs, knowledge base tip sheets, escalation procedures, notification requirements, schedules for batch jobs, lists of interfaces, details of interfaces, expected outcomes, lists of vendors, data sheets, user guides, admin guides, support levels and contacts. Requirements documents and functional specifications should also be shared with the operatonal support team for reference, manitenance and operational support puproses.


Support knowledge transfer usually takes place in progrsssive iterations in the form of meetings between the project development team and the operational transition team, it is a series of engagements of experts to transfer knowledge, review details of the software and identify all the transition requirements including the development of a transition plan and its execution.


Operational procedures are covered in the documentation above and also include run books, special processes for data archiving, licenses renewals, IT business functions and upport such as security audits, threat analysis and similar processes.


Production readiness covers the setup and installation of the software, user configuration, secuity profiles, smoke testing, functional spot checking, final hardware configuration and monirtoring systems (reportsing / dashboards) setup.


Finally end of life support should be considered at time of transition to ensure the user population understands how to dispose of the software at end of life, how to extract data and migrate into industry standard formats as needed.


The links below provide some more details and templates


https://www.projectmanagement.com/content/processes/10352.cfm


https://www.projectmanagement.com/content/processes/10350.cfm 

Performance Challenges on the Cloud

 

 

A typical cloud implementation could have hundreds of CPUs running in parallel. Some cloud solutions could be like an S-class Mercedes, however to leverage its muscles, it needs to be configured and fine tuned to reflect an efficient model. Examples of factors affecting a cloud implementation performance would be the number of Key Figures in an Integrated Business Planning (IBP) solution. The more Key Figures the higher the demand on the system and lower the performance.

 

Examples of common cloud performance challenges I have seen on SAP and Salesforce implementations are:

• Slow login time which is usually driven by network latency, demand on the enterprise SSO or other security system, firewall settings, or network device configurations.
• Dropped connections could be difficult to troubleshoot. On one implementation SAP users would receive a dropped connection error on an intermittent basis after about 30 minutes of being active on the system. Two weeks of troubleshooting uncovered the root cause of the issue was not due to the SAP cloud, but a misconfigured load balancer group of servers at one of the client's data centers.
• Initial load of templates, views and report runs are common issues when customers process large amounts of data. On a healthcare SFDC implementation the customer had a Contacts view for all its members, a whopping 1.5 million records. Obviously loading the view would take a few minutes of its agents staring at their screen. Educating the client on customizing the views to show members in a particular region, or who match certain filter criteria allowed them to view smaller data sets which were also more meaningful to their work.
• Refresh time is also a factor of the amount of data being retrieved, the browser
• Simulations
• Long running queries

 

Vendors constantly monitor their cloud operations checking memory utilization, background jobs status, CPU utilization, table sizes, system activities, and other performance KPIs to ensure optimum performance for their customers.

SAP key figure calculations can reach 10 million rows per second for its IBP solution in some implementations. Some factors that can affect that metric are data aggregations, projection, joins and uinions. In general loading a Planning View is dependent on the slowest Key Figure atomic calculation speed and the volume of data it processes. Using filters can sometimes be effective if it reduces the number of stored Key Figures that are defined as inputs to a calculation chain. However if filters do not affect the number of key figures and only affects data size the impact on performance might be minimal.

 

Are You Asking Your Engineer to Do the Impossible?

It is important for engineers building systems to understand how the organization will support the utility of their end product. I was asked to weigh in on a dispute between an IT vendor and a large multinational corporation. The vendor claims the IT security work has been delivered and they installed the systems and built the infrastructure needed. The IT sponsor at the corporation claims the implementation is not working.

 

Upon closer observation and after discussions with the technical team members I was able to identify the root cause of this confusion. Both entities were correct, the vendor indeed did deliver the work per technical spec, and indeed it was not serving the business objective the sponsor expected.


In a nutshell, the technical implementation was done correctly. However the way it was used by end users was not what both parties had envisioned causing certain portions of the solution to go out of sync with other components in the system, causing configuration errors yielding diluted value of the implementation. What was missing was an organizational policy that guides end users to follow certain process changes. Once the end users would follow the new organizational policy, and back doors were no longer allowed, the system components would be in sync and operate correctly.

 

The summary of this experience is that for a technology implementation to work properly the following need to occur in advance.

• Clearly articulate the updated operational process flow
• Ensure governance and policies support the new process flow
• Develop controls in the IT implementation to to enforce the policy

Without the three components the net realized value and user experience will be suboptimal. This is of course assuming all other standard best practices of system development have been followed from concept to deployment.

Closing on Poorly Contracted Projects

I was once asked to help with a large transformation program at a fortune 500 product development company. They had outsourced several IT security transformation projects to a vendor. The contract was very poorly written, more assumptions than deliverable were listed, the deliverables listed were not measurable and there was too much loose information. The projects which were supposed to take six months each ended up taking three years.

 

I was faced with one of two options, spending dozens of hours sifting through project change requests, meeting minutes and status updates for three years' worth of work, or come up with an agile, fair, and meaningful approach to close on the project. Luckily, I was provided a punch list that a former project manager in the past had felt was all the work items missing. The punch list helped me make the decision to choose the latter option and follow an agile approach to close out on the project. I followed some simple steps;

 

1. Setup weekly punch list calls
2. Defined my role and the objective of the effort
3. Went through the list each week
4. Compared to the original contract
5. Identified any gaps

 

These five steps might seem straight forward, which they are, except when you have two teams, one representing the client always asking for additional items which are mainly operational enhancements and not project deliverables; and another team which is the operational team on the vendor side fulfilling these requests, not realizing that they are also playing a role as the project vendor team. This is the crux of the complexity. It is not that the projects were not closed out, and not in production, they were indeed open projects, but the work delivered is well in production use for years, with new teams on board from both sides and now people are not considering the original baseline or expectations, they are comparing with the day before. It was a continuous bleeding scar for both companies.

 

So the trick in closing these projects in addition to the agile process above was assertiveness, clarity, separation of duties and the ability to act as a mediator and setting a clear measurable deliverable for each open item, with the confidence to act as a business analyst or contract manager specifying the measurable deliverable as needed on the go.

When its Time to Close a Project, Close it

It's in the best interest of the project, its sponsor, the team and the business to close a project when work is delivered and value is realized. I have come across several instances where the client feels the urge to keep the project open for one reason or another. Here are common cases where project teams keep the project open.

 

• Waiting for a new feature in a future COTS product release
• Few minor defects not fuly resolved
• Extra funds are available
• It will be hard to get approvals for a new project
• No guarantees that team members will be available in the future

 

None of these reasons are legitimate reasons to keep a project open. Open projects are like potholes, they only accumulate trouble until they get out of control and then need a complete removal and replacement with a new project. If the business value has been delivered, close it, move on and start a new one if needed when the time comes.

 

What is an IOT Platform

IOT Platforms come in different flavors and capabilities. IDC defines an IOT platform as follows:

 

• connects to and manages IOT endpoints
• ingest and process IOT data
• visualize and present IOT data
• builds and hosts IOT applications
• integrates IOT data into existing applications

 

Do you have a different definition?

I Received PMI Agile Certification This Week

This week I sat for the PMI-ACP exam and passed. It is a 3 hr 120 question examinations touching on several areas of the agile practice. As Certified Scrum Master, it required minimal preparation.

Do Not Shortcut the Instruments or Tools to Realize the End Product

This weekend I invited a close friend of mine to visit a nonprofit leadership center I oversee to give us some advice. He is a seasoned executive at a large retailer and supervises dozens of stores around the region. As head of the institute, and the main instructor my attention is usually drawn to compliance, curriculum and the overall performance of the organization. As he walked in he joined the trailing part of a financial reporting meeting and offered a couple of suggestions for a new program, we then proceeded outdoors to take a holistic view of the organization from outside. What comes next was very interesting.

He pointed out weeds on the sidewalk, and some stains on the building trim. Then he pointed out a few items that are not obvious to someone like myself who mostly focuses on the results and end deliverable. In other words he was able to make me realize that sometimes we get so entrenched in the mission or objective of the project; or we are operating on an agile framework delivering the next generation product while in the process the tools and artifacts used to get there are sub-quality.

Quite often on complex technology projects the team is busy delivering product value and checking off the deliverable list, while in the process they neglect the tools and instruments used to achieve those deliverables. For example the engineering team might produce a set of technical documents, however the document might not be totally polished like one that is being presented to the end user; margins might be inconsistent, different fonts on the same page, figures not numbered.

Agile project management should not mean producing internal PMO artifacts that have mismatched fonts or different font sizes, margins that look off, or a document that is lacking a table of contents. While it is true the client will never see these documents, and its only for the purposes of planning, but the fact that an instrument overall quality and aesthetics will eventually reflect the end product.

The lesson I learned is that a good balance across all areas of a project or organization is required. It is not enough to have a quality product, even if it sells well. The process in achieving the product also needs to be totally shiny and attractive even though the client is not paying for it.

Common Project Initiation Check Points

Businesses initiate projects differently, some places have long cumbersome tasks that need to be completed prior to kick-off a project. Others might be simpler. I share some common tasks that usually are required for a new PM to get through before she can have that first team kick-off.

Sponsor Funding Approval

This could also be referred to as appropriation request approval, budget allocation approval, capital investment approval or charter approval. Basically the sponsor signs off on a document that he has the available needs funds and specifies the total dollar amount of these funds. Some organization have set times when approvals are made and sent to the IT/PMO organization, in other cases it might be on an ad-hoc ongoing basis, where requests are queued up and processed by the IT/PMO organization at specific dates of the month or the quarter.

Resource Allocation Approval

This approval usually is made by the organization which is delivering the work. If it is an IT project then the IT group that will actually design, build and test the product or system being developed as part of the project charter. The fact that funding is available by the sponsor does not guarantee that the delivering organization has the capacity to work on the project during the period wished by the sponsor.

Technical Dependency Approval

This approval is usually obtained from the technical center of excellence, for example the enterprise architecture group, cloud center of excellence, security standards group or the group that is technically governing the organization's standards. A business might have the funds through a sponsoring organization to fund a project, and the delivering organization might have the resources (team, tools and supplies) to deliver, but there might be a major technical dependency preventing the feasibility of the project. For example in the case of an IoT enablement project, there might be a security identity management architectural pending problem, which the project requires resolution prior to going live. Another example in the transportation sector could be getting approval for use of certain material in paving roads to meet certain standards which has not been obtained yet.

Vendor Statement of Work Approval

Many projects depend on a third-party vendor to deliver the project. In order to initiate the vendor SOW process, all the above approvals might need to be secured. Other items that are common as well, are charge numbers by the Finance organization, Project ID number by the PMO and even in some cases names of lead resources such as the Project Manager, the Technical Lead and the Quality Lead.

Delivering Organization Statement of Work

The delivering organization usually would like to provide the sponsor with an internal SOW or charter that specifies the scope of work being delivered and any assumptions, dependencies and high level roles and responsibilities. This is different than the sponsoring organization
statement of work or charter which is discussed above and is mostly a guarantee that money is available to execute. The delivering organization is the one responsible for ensuring the project is delivered per specs. In some case the delivering organization does the work, or might outsource it to a third-party-vendor as discussed above. The delivering organization charter is the agreement between that organization and the sponsor. Whereas the Vendor Statement of Work is the contract between the delivering organization (prime contractor) and the third party vendor or organization (subcontractor)

In summary there are many organizational check-points that a project manager should be aware of when kick-off a project at a client or even internally for the employer. In large businesses, these approval points and processes are not always, or usually not in sync, and some might need to be in parallel.

The Most Important and Most Neglected - Business Rules

Over the years the most important issue I have seen neglected on a transofrmation project is an honest thoughtful discussion on Business Rules. What should the process look like under the different conditions. Business rules come in all forms and levels of complexity. I share a few examples below for the purpose of clarity.

 

A healthcare provider member who wishes to renew her policy for her 7 year old child and 19 year old college student. The business requirement can have different rules, here are some:

• Rule A: Income Level: Family is low income and hence have an extra 10 day grace period
• Rule B: Residence: Family lives in rural counties of the state and hence is eligible for a 45 renewal window, versus same family living in the major cities of the state which has only a 30 day window for renewal.
• Rule C: Age: 19 year old child reached his 19th birthday less than 90 days prior to his policy expiration is treated differently than more than 90 days prior to expeiration date.

 

An example from the supply chain vertical related to demand forecasting and planning could be dependent on order cancellation business rules, for example:

• Rule A: Orders returned due to defective items that are reordered on the same order, should not be removed from demand
• Rule B: Orders returned due to defective items and are reordered on a new order, should be removed from the demand of the month of order, and reapplied to the month of the new order.

 

Projects of all sizes usually neglect business rules when designing and delivering a system. Business rules are the most important part of the process, for indeed that is where decisions are made. Decisions are where the bug are found in the system. Poorly thought through business rules automatically equates to bugs, miscalculations, data quality issues, rework, frustration and utlimately redsign and worse sometime a compelte overhaul of the architecture

 

 

The Cookie Cutter Project

We all come across these straight forward projects, right? The project that was done half a dozen times before, that it almost feels like an operation to the project team. Deploying a new infrastructure at the fifth location of the company, or extending an automated software application service to a new region after three successful deployments elsewhere. Sounds familiar?

Many project teams come across these cookie cutter projects each year, and also many of them end up having a hiccup. NASA shuttle program is one well publicized example. It was not the first few times a mission was launched when it blew up into flames. The program has been very successful for years with dozens of missions. Smaller projects experience the same. Several things project teams need to keep in mind with cookie cutter projects are:

Projects are Projects
A project is still a project, even if done before in a similar context. the fact that a scope of work has been identified by someone as a project means it inherently has some risk, and is deemed by the some in the organization to require closer baby-sitting than a typical operation. On a recent project I was leading for a high tech materials company supply chain, the team viewed the project as a cookie cutter and saw no need for tight toll gates, reviews and checks and balances. After all it was their fifth time to deploy this service for ordering the end product by their business customers. It took extensive coaching and education to explain to the team that if the project came to us, it means that the supply chain service line, as well as the IT PMO have determined it unique enough to be staffed as a project, rather than an operation.

Identical is not Similar
Studying geometry in eight grade was not a total waste for those who did not end up studying engineering. Similar and identical triangles are not the same. Unless a project is identical, to a previous project it should be considered unique and requires progressive analysis. Similar projects will have one-off requirements, or some special handling, or a change that occurred since the latest iteration of the similar project. This is exactly what happened with my project, during the time between the latest deployment at location A and the deployment at location B was five months. A couple of key processes changed across the the supply chain on the other side of the ocean. This change added risk and requirements that location A did not need to deal with. the project team for location B was not aware of this enterprise level change. Similar is not identical.

Humility Pays Back
We all are well aware of Titanic, the vessel that supposedly would survive a crisis in the middle of the water. Watching reconstruction videos of airplane mishaps occurring 40,000 feet high over a vast ocean, and how these failures were resolved has been not only intriguing for me as an engineer and project manager, but also an eye opener. No matter how advanced we human beings become, no matter how many sensors we have on an aircraft, or an Internet of Things (IoT), we will never beat the power of unknowns and unseen, nature and the Creator's will. Humility in dealing with projects' technical scope, technology, science, external factors, human behavior and automated electronic processes that usually run in the background undocumented properly is just good business sense at minimum.

So a cookie cutter project is more than a cookie, its a cake with some custom toppings that could mess up the whole cake if not properly placed.

Enjoy the cake !

Risk Management and Normalization of Risk

Once in a while we come across a failed project, poor decision or worse a catastrophe. The individual or team behind the decision might be very well experienced. When teams take on risks and plan well ahead for the impacts of these potential scenarios, they build competence and are well equipped to handle these risks. However is many situations the risks are mitigated and no negative impact is ever realized, causing teams to be more aggressive in risk taking, and hence the normalization.


In other words, successes and error-free delivery could lead us to gradually accepting higher levels of risks simply because the subsequent effect from a previous risk never occurred. When this normalization occurs we start to operate outside of acceptable parameters without realizing, potentially falling into trouble.

SAP Planning Areas Considerations

Without fine tuning your cloud implementation you might realize less than optimum performance without even noticing. This post shares some recommendations that could fine tune an SAP planning view performance.


Sizing
Verify sizing post implementation is accurate after data is loaded as part of go-live activities. Sizing includes data storage, processing memory, data density (number of relevant data output per time period), ex: 1 sale per month, will not be caught in the weekly runs), and safety factors. Processing data on a more frequent basis and keeping the results on the planning view affects the remaining free resources (memory and storage). Sizing should be done during the cloud service acquisition, at end of blueprint, as part of performance testing and after go-live.


Configuration Complexity
Master data types and overall attributes should be kept as minimally as required. Usually clients use 20%-40% of the attributes they have defined in their implementations impacting performance with no true business value realization. Using non-key figure attributes of master data types as root attribute in a planning level is another approach to improve performance. Minimizing the number of calculations that include input levels is another way to improve performance, however care should be taken to avoid the need to increase the number of key figure values needed to store data. On the fly transformations should also be avoided to avoid performance bottlenecks.


Calculations
The approach used to perform calculations can significantly impact performance. Examples are the selection of key figures for a calculation, the calculation chain, stored key figures inputs, key figures base planning levels, placement and configuration of filters among other factors.


Planning Views
Keeping planning views to a reasonable number of rows is a generally recommended practice. Usually setting the rows to 2000 - 5000 does not impact performance negatively. Utilizing VBA-based templates instead of formula-based templates is another approach to improve performance as recommended by SAP. Using filters in templates when saving and opening templates is highly recommended to ensure reasonable load times. In SAP 1708 users will receive a warning message if no filters are defined in a planning view.


Running Operators as User-Defined Scenarios
Algorithms such as multi-stage inventory optimization affect the whole supply chain network. This large run-time can cause time-outs when run in simulation mode. A recommendation is to run these simulations as user-defined scenarios for improved performance.