Search My Blog & Website

Wednesday, October 04, 2017

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.

Wednesday, September 13, 2017

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 some up with an agile, fair, and meaningful approach to close on the three. 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?





Sunday, August 13, 2017

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.


Sunday, August 06, 2017

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.

Thursday, August 03, 2017

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.







Monday, July 24, 2017

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
 
 

Friday, July 21, 2017

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 !

Wednesday, July 19, 2017

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.

Tuesday, July 18, 2017

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.









Wednesday, January 20, 2016

Minimal Attributes for a Good Story

Authoring good stories for a developer is an art and science. The business analyst needs to be able to articulate the pain the customer is facing and translate that into a meaningful requirement for the developer to implement. 

Equally important is the need to ensure that the requirement meets the objectives of the business. Below are some attributes of good requirements or stories to ensure the delivered implementation is what was expected by the customer.

Mandatory Attributes


  • Requirement ID: Unique Number with a dot followed by digits for sub requirements
  • Requirements Title: Free Text
  • Description: Includes a function, actor/role, input and output
  • Requirement Origin: Could be the User, sponsor, BA, developer
  • Requirement Specification: Originated (base requirement due to a business need), derived (from another requirement), implied (assumed by default), emergent (new due to a change)
  • Requirement Acceptance Criteria: Free text explaining how to verify a requirement has been developed
  • Priority: 1, 2, 3 (1 = high, 3= low)

Optional Attributes

  • BA Comments: Free text explanation or notes from BA to clarify points, provide examples
  • Requirement Validated: Yes, No (has it been validated by the business)
  • Business Value: The purpose of this requirement, the pain its solving or gain its providing to the business
  • Verification Method: Demo, Testing, Inspection

Wednesday, December 30, 2015

Basic Design Document Components


1.       Systems Context Diagram

This illustrates a high level concept of the WMS system for each release and provides a black box perspective showing interfacing systems, release boundaries and high level view of the system main blocks.
 

2.       Functional Concept

Provides details of the functions of the WMS release and the design details of each function. It includes functional diagrams to show locations of where functions are implemented and an inventory list of details of each function. It includes coding and implementation details for each function.

3.       Entity Relationship Diagram

Offers a detailed view of the relationship across the various SFDC objects including dependencies
 

4.       Operational Concept

Provides details of the operational design of each function of the system, including triggers rules, workflows, and thresholds. It also includes data flow diagrams, process flows, field dependencies, formulas, and report / dashboards designs. The design has details of the all the coding and implementation decisions related to the operational aspect of the system.

5.       Design Constraints

Provides an understanding of any limitations imposed by SFDC environment, business rules, scalability or other non-functional requirements, cost and budgets, operational procedures and development tools.

6.       Interface Details

Includes definitions of interfaces, fields and data details across interfaces, data transmission attributes (frequency, source / destination formats, security, , interface controls and rules.

7.       Integration Design Spec

Includes details about interfacing systems, configuration needs, web services, APIs, XSDs and other integration styles used in the design such as messaging gateways, mappers, dispatchers, control buses and service layer details.

8.       Non-Functional Design Spec

Includes all non-functional design decisions and configurations for security, scalability, accessibility and interoperability.

Tuesday, October 02, 2012

Estimating Project Efforts

Project effort estimation involves both science and art. There are well known approaches and techniques for estimating project sizes and effort, these approaches and techniques however do not work well with all project sizes. For example, small projects (less than 5 team members) are severely impacted by team instability, and models used for large projects (teams larger than 25 people) are not applicable to small projects. The best approach for small projects is a bottom-up estimate using analogous techniques to speed up the estimation exercise.

In estimating a common approach is to count, compute and assess. Counting involves counting the number of elements in the projects, such as features, capabilities, web pages, use cases, stories, reports, requirements or similar components. Computing involves calculating an estimate for a per unit count, counts could come in different T-shirt sizes (small, medium and large). The computation should always take into consideration a range and not a fixed value. For example to compute the average time for developing a use case, we should consider the worse case situation, the best case and the most probable. Using a formula like the PERT formula we can then estimate the duration, cost and effort for the average use case development. The same exercise can be repeated with different stages of the project, for example the use case definition, design, development, testing, documentation and training. Assessments are the art part of the estimation and are based mostly on expert opinions and "gut feeling". There is no hard rule on when to use expert opinions, it depends on the project, the experts weighing in, the complexity and novelty of the problem being addressed by the project. In many cases experts opinions have been found to be very reasonable and a great quick estimate approach, however in many more cases it has failed its originators due to factors not considered or accounted for when the expert judgments were rendered, bottom line, use with caution. Some good resources on estimation are Steve McConnell's book software Estimation: Demystifying the Black Art. 

Monday, June 20, 2011

Aspiring World-Class Universities: A Snippet On Clemson

As it becomes more challenging to compete in a global village, institutions of higher education look into their back pockets for ideas to differentiate and grow. These aspiring institutions do not need to replicate what top universities are doing, on the contrary their innovation in distinct new ways can unleash value and competitiveness.

A shining example is Clemson University in South Carolina. Clemson has been the traditional southern unviersity focused mostly on agriculture and mechanical engineering. Clemson has been able to transform its positioning and value proposition through a well articulated study of the regional economy. South Carolina had embarked on an economic development and conversion process to make the state one of the leading automotive regions in the US. Clemson formed a strategic alliance partnership with BMW [1] to recreate itself as the premier motor sports and automotive research and education university.

This transformation effort at Clemson was adopted and supported at all levels of the university - a key requirement for success - as was reflected in Clemson's vision statement [2], to be from among the top 20 public US universities. Clemson was 23rd in 2010 [3] up from 33rd in 2005 [4] and 74th when Clemson's President James Barker took office in 1999 [5]. Within a decade Clemson has been able to transform itself and achieve a new position through leveraging regional changes and collaboration with others outside higher education.

Each University will have a different catalyst for transformation and very different root-causes that challenges its aspirations. Leading universities are those who can carefully articulate their business challenges, understand the complexities of the societies and constituencies they serve, and apply the best strategies, approaches and frameworks to design an architecture that makes a lasting change.

______________________________________________________________

[1] BWM, Clemson and the State Begin Historic Partnership, Clemson World, Fall 2002, available at http://www.clemson.edu/centers-institutes/brooks/news/BMW.pdf

[2] Clemson's Vision Statement, http://www.clemson.edu/administration/president/vision.html


[3] Clemson Ranks 23rd Among Public Universities, http://www.clemson.edu/media-relations/article.php?article_id=3019

[4] Virginia Tech Undergraduate Engineering Ranked 14th in US, http://www.eng.vt.edu/newsitems/pdf/COEundergradranks05_dup.pdf

[5] Clemson Civil Engineering in Top 20, http://www.swampfox.ws/clemson-civil-engineering-program-in-top-20

[6] Picture, courtesy of Clemson University International Center for Automotive Research (CU-ICAR), http://www.clemson.edu/centers-institutes/cu-icar/

To Read Further:

Thursday, May 19, 2011

New Responsibilities for Higher Education

In most nations across the globe, in particular the progressive ones, higher education has been driven by the societal needs and challenges. Both public and private institutions of higher education play a paramount role in the readiness of a nation to address its needs at a strategic level. While public policy play a major role in the direction of these institutes, many institutes also are on the forefront playing major roles in shaping the progression of technology, social sciences, life sciences and other major domains of knowledge, and in some cases even influencing public policy.

Today's challenges facing societies across the globe are of a new nature. They are complex, complicated and require in many cases a complete new paradigm of thinking and problem solving. Approaches to solve the economic crisis, unemployment, social ills, resource sustainability and many other new types of challenges require a new way of thinking and responsiveness. The transformation of many societies from product development to service development has introduced a major shift and position of higher education. It is no longer an option for many. As less manufacturing jobs become available more emphasis on knowledge-based economies becomes a key success element.

Optimized learning is a new responsibility on the shoulders of higher education [1]. Learning and knowledge delivery can no longer be one-size-fits all, nor can it be at an abstract level. Optimized learning allows students to become effective learners capable of meeting new challenges they encounter and allowing them to be effective workers and members of the society. Optimized learning allows for the achievement of learning outcomes that meets not only educational standards, but also the growing needs of society.

Optimized learning means that institutes take on the responsibility for :
  • improving learning abilities
  • increasing the number of students who persist and succeed in programs
  • closing the gaps in achievement while raising the bar.
  • developing curriculum and courses that directly reflect societal needs
  • engaging and leading partnerships with K-12, private sector, non-profits, government and other institutes
  • setting and developing standards that reflect how well an institution addresses societal needs and challenges
  • creating learning-centered environments

In addition to optimized learning, another demanding responsibility on institutes of higher education is their public accountability and its increasing scope. For example community colleges spending has increased more than 25% between 2003 and 2009 just to keep up with state and federal mandates and reporting requirements [2]. Most of this spending is reflected in information systems expenditures and satisfying legal liability.

Despite the fact that many of the challenges facing institutes of higher education are a result of decades of poor public policy and miscalculated strategic initiatives out of their control, they realize the need and responsibility to streamline business processes and offer learning centered capabilities to maintain their position as a driving force in shaping and developing local economies.


What other challenges do you believe higher education needs to deal with? How have you seen others address these challenges?



[1] "Partnerships for Public Purposes: Engaging Higher Education in Societal Challenges of the 21st Century", National Center for Public Policy and Higher Education, April 2008.

[2] "Industry Profile, Community Colleges", First Research, May 16, 2011.