Project Approval Lifecycle Part 1

Project Approval Lifecycle

Lessons from the California Department of Technology

Do you want to have better success implementing project deliverables? Do you think you know how to solve a business problem but not sure how to initiate a project?

The CA Department of Technology (CDT) offers an excellent set of tools and techniques, that with practice, a dedicated project team and a deliberate effort will get you on your way to initiating and planning a successful project.

The tools I am referring to are the Project Approval Lifecycle (PAL) stage gate templates and instructions. The techniques include focus groups and meetings with subject matter experts, key stakeholders and managers, depicting As-Is business processes using conceptual and process flow diagrams, and developing business narratives of the business problems and opportunities.

The PAL process defines the stages (stage gates), which if followed closely will help to move your project from just an idea at initiation to a formal plan for procurement, and the knowledge to support a successful project execution phase. The goal for all projects is to have the foundation of the project so well defined, documented and understood that the execution phase will be in the best shape to handle technical complexities and unanticipated issues as they arise.

The PAL process employs four templates, which are named Stage 1 – Business Analysis, Stage 2 – Alternatives Analysis, Stage 3 – Solution Development and Stage 4 – Project Readiness and Approval. The names themselves provide a high-level overview of the activities the project team will complete. But don’t let the name fool you, there are many aspects that the project team must confront to produce quality analyses and acceptable documentation.

The first template,

Stage 1

– Business Analysis will have you focus on defining the project team, business background, stakeholders, business problems and/or opportunities and measurable objectives. This seems like a simple list of items to tackle, but it’s not. The first step in defining the project team is to identify staff who have the business knowledge and the willingness to take precious time out of their day to support a new effort which will not see benefits for some time. These staff members must represent the entire process which will be affected by the eventual solution and be willing to work together to describe the current activities no matter how poorly each is executed. The goal is to describe the current situation well enough that there is context for the team who will eventually help develop a solution. If your audience does not understand the context no matter how bad the situation is, they will not be able to help solve the business problems and will not know how to help meet the business objectives. This means that all staff who play a role in the business process will need to be represented to know you have captured the context fully. When the project team does not know how to describe the context of the current situation the staff that is later employed to help solve the business problems will be in no place to help. Estrada Consulting has been involved in many application development projects and can identify those organizations who have prepared themselves to tackle the difficult challenges of implementing a solution that hits the mark. It takes the experience of senior business analysts to be able to coax the information from the project team and develop the project artifacts that go into the Stage 1 documentation.

For example, imagine you receive a business problem that states, “The business is not meeting its goal to complete customer requests within 4 business days”. The corresponding objective may be: “Reduce the number of requests that are delayed due to missed communication by 20% within 6 months of solution implementation”. This appears to be complete from a SMART (Specific, Measurable, Achievable, Realistic and Time Based) perspective, but there is not enough context for someone on the outside to understand how to help solve the business problem nor satisfy the objective. The reader does not really understand why requests are being delayed. The objective provides some insight that communications are being missed. This seems simple to address by not missing any future communications. We know that it is never this simple and if we had more context, we would know why these are missed and how to help. If the business background description were complete we may find that the reason for missed communication is that the current process relies on email alone to communicate activities performed to complete a customer request. Now the project team or an outside resource can begin to understand that the staff who manage customer requests are overwhelmed with email, which can be solved in a number of ways. By knowing the context we can begin to determine if we have seen this problem before and what approaches were successful in similar situations in the past. I may not have the right solution, but the community you rely on to provide solution alternatives will be able to provide a meaningful solution.

For mature organizations that have well-stated policies and procedures the answer to why the delay is occurring may be more easily determined by an outside person by performing a document review. However, most organizations are facing new business problems and do not have these tools at their disposal. As a departure from the CDT formula to define the As-IS Business process at the later Stage 2 – Alternatives Analysis, Estrada recommends for less mature organizations or those facing a new business problem, your organization analyze the business process fully before even documenting the business problems and objectives. If the project team members can’t describe why they believe the problem exists and is not confident enough to put it in writing for the entire project team to see, we contend that the business problems are not completely known and the objectives when met will not have satisfied the needs of the organization. It is easy to think you know why the business is encountering a problem, but without knowledge of all the actors and steps to complete the process, you will reliably miss important issues that will reduce the affects of the solution.

It is likely the project team will spend more time than expected to define the business background since it is extremely challenging to describe something that one does every day. This is an iterative process to describe every step of the process and make sure the project team’s and stakeholder’s input is considered. This is when an experienced business analyst can provide the most value to ensure that when conversations stall, the right probing questions are asked to keep the discussion moving along. An additional benefit of doing the As-Is Business analysis at Stage 1 is that your team will learn the “hows and whys” each member does their work. You will also find situations where you can make immediate process improvements that take little effort and will contribute to the success of the project. This can create a synergy among the team where members will look to help each other and understand the trials of their co-workers. The Stage 1 – Business Analysis along with the Stage 2 – Alternatives Analysis can often take the most time to complete within the PAL process, which it should. Estrada Consulting recommends an organization spend 3 months at a minimum to complete the Stage 1 documentation. For more mature organizations, that have documented the policies and procedures that describe the business background and context, this may only take weeks to complete.

Stage 2

focuses on the alternatives analysis and analyzing those against the current IT environment from the technical and financial perspectives. Depending on the size and nature of the project and the number of stakeholders the S2AA can take as little as 3 to 6 months and as much as 6 to 12 months to complete.

The S2AA begins with defining the mid-level business requirements that can be derived from analyzing the AS-Is business process flows and narratives, and drive the market research. Having a clear understanding of the business background, problems and mid-level business requirements is paramount to conducting quality market research. This knowledge will allow the organization to clearly describe to your audience what the business needs are and how you plan to measure success through SMART objectives. No matter the type of research the organization plans to conduct from research on the Internet to a formal Request for Information (RFI), the research analysis and assessment team will have the criteria to evaluate proposed alternative solutions. One of the biggest returns on the market research investment will be quality analysis of the advantages/disadvantages of each alternative, which will be based on well-defined evaluation criteria. The market research will also help the project team understand what is available out in the market and the cost of each alternative. This knowledge can often translate into more meaningful requirements that can be prioritized. The requirements become more meaningful since they can be evaluated and categorized more easily as mandatory versus optional and based on the market alternatives, the most important requirements begin to surface among the team as it argues for the features in each solution.

Another important aspect of the S2AA is to document the financial impact of the current environment and associate a value to the products and services provided by the organization. The financial analysis will allow the project team to document the added costs (if applicable) to determine if the benefits in implementing the solution can be justified in efficiencies gained or when business growth can be better managed. For government projects the goal isn’t typically to reduce costs associated with staffing levels, rather to improve efficiencies to address growing demand. Therefore, the Financial Analysis should not focus for government organizations on reducing costs as the primary focus, rather to better understand what the new normal will cost against current expenditures to provide the costs that are associated with growth in the business when constituents ask how money is being spent and why. Information technology projects can be expensive and typically cost more than what has been planned when the work to complete these two stages is not done properly. Most projects that look to implement an electronic solution for a paper-based, manual process that can no longer sustain the business needs will likely increase operational costs and total cost of ownership but will ensure the likelihood of efficiencies as the business continues to grow. When the organization can rely on the cost estimates at this stage, it will be better prepared to adjust to the new costs and will not be surprised with an out of control budget as the project progresses through the execution phase.

Once the organization has completed the S2AA and has determined final requirements, calculated a budget and identified a recommended alternative solution, the difficult work to define detailed solution requirements comes into play. This is the Stage 3 – Solution Development work, in which the detailed requirements are derived from the mid-level business requirements and the project team decides on the approach and methodologies to procure goods and services. Depending on the estimated costs for the project the organization may need to also prepare a Budget Change Proposal to acquire additional funding. In any project that is estimated to surpass the organizations delegated purchasing authority and/or requires a BCP, there are additional forms and oversight that CDT will require while completing the Stage 3 and 4 documents and on into the execution phase of the project. CDT offers an extensive resource to draft the procurement vehicle which describes each section that should be considered based on experience from previous implementation work, and an explanation that describes the content that should be included. During Stage 3 most time will be spent defining detailed solution requirements

Continue Reading Part 2

Leon Casaubon Sep 18, 2019Nov 7, 2019

Re-Thinking Communication on Complex Projects Part 1

Since the initial Chaos studies by the Standish Group in 1995, the industry has been trying to resolve the
high failure rates of projects. Since most organizations trying to address the problem were associated
with project management, improvements were recommended in the entire project environment with a
high-level of emphasis on the project manager to ensure the right conditions exist. In 1995, when I
reviewed the results of the Chaos study and the many lessons learned published from industry sources, I
created a term I called “Informed Misperception.” Today, I still believe that this one factor is the root of
many project problems.

What is Informed Misperception (IM) and what causes it?

Just think about how many messages you interpret from others in a given day. Now recall how many of
these may have had a misinterpretation at first that needed to be clarified and explained. This is a
natural phenomenon of communication. In projects, communication between some parties needs to be
complete and precise. Rarely, however, do individuals feel like they have the time to get to complete
and precise communication on many points that matter. In fact, there are many conditions that worsen
the actual level of completeness or precision each individual delivers.
Consider the following conditions:

 A technology designer is in a meeting to communicate design.

1. The design individual’s supervisor or lead is not in the meeting.
2. Few, if any, peers exist for interpretation of the design.
3. Parties that have to use the design to complete implementation are present.
4. There are many individuals in the meeting.
5. The design individual is remote and the meeting is a virtual session.
6. The meeting is scheduled for an hour.
7. The content of the design took over 3 weeks to define.
8. The documentation for the design is not detailed.
9. The design individual is a contracted staff member of the implementation vendor.
10. The business users are present; they intend to ensure their requirements would be met
with the design.

While the list of conditions could expand from the list above, the intent of this document is to explain
enough of the problem to recommend a solution.
What is the potential impact for each of these conditions?
For the numbered items above, here is a brief explanation of only one or two scenarios with each that
could lead to misperception. Note that in all cases, the design individual is likely not trying to be vague
or uncooperative; however, when time is short and demands are high, the level of stress for an
individual can build to a level that requires a relief valve to open – more on this after the explanations
for each condition.

1. The design individual’s supervisor or lead is not in the meeting: when technical supervision is not
present, there is a chance that the individual’s design is not an internally approved design nor that
the formal process for design has been followed. This may have no bearing on the quality of the
design; however, systemically unsupervised design tends to be less focused on what the end system

needs to do and is more focused on technical accuracy. This means the system could be doing the
wrong thing very well. Lapses in supervision have been known to drive poor design or
implementation since the individuals can mean to do the right thing, but have less incentive to
check their own work.

2. Few, if any, peers exist for interpretation of the design: when individuals available to receive or
interpret design, if their skill level for the kind of design being presented is low, the design individual
should try to alter the presentation to explain not only what the design is, but why the design is like
it is. This is to help participants to understand how the design allows the implementation to achieve
what the business needs. Of course, this takes additional time, and most individuals will have the
pressure of time constraints that would lead to short-cuts in explanations. This is a dangerous
situation if you have less than adequate design resources. Knowing that the participants are not
able to interpret the design, the explanations can be vague and the answers to questions can also be
vague and superficial so that the details will always have to come later (or perhaps never). Even if
the designer is excellent, they might not understand the business enough to consider some aspect
of design that should have been incorporated. Due to time constraints, the details are often left for
later discussions for which there seems never to be enough time.

3. Parties that have to use the design to complete implementation are present: while this is a very
good practice, the more parties in the room can mean that the people who really need to
understand the details of the design might not have enough time to get what they need. Formal
meetings hinder the right kind of progress, at times. When the details are discussed and questioned
(is this what you mean, is that what you mean) someone very familiar with the business needs to
ensure that the business intent is still going to work with the details that are being clarified. This
level of clarification rarely takes place, but is the most essential. If business users review
implementation every two weeks and get to adjust the functionality to their needs, this might not
be a problem. If the design is followed with many months of implementation prior to business
review, there is a lot more risk that the design, as implemented, won’t do what the business needs.
In public, formal meetings, when detailed questions of the design may not have answers, the actual
answer can be vague. Implementers start to make assumptions and add details they believe are
accurate to which an incomplete designer could respond a simple “yes.”

4. There are many individuals in the meeting: again, as the meeting grows in participation, the time
becomes less to address all concerns or clarification needs. The conversation tends to elevate to a
higher level to complete all conversations at one level that would never provide the details
necessary to truly interpret completely. The designer also may not get the feedback required to
ensure the design can be adjusted, where needed. The higher level of individuals in the meeting or
design session can also imply that other organizations are trying to cover their responsibilities
through participation. Coupled with other of these conditions, all individuals will tend to say enough
to ensure their point was heard or documented, yet often is insufficient to convey all of the meaning
since there might be objections individuals do not want to address in this large of a meeting. This
can lead to much more ambiguity.

5. The design individual is remote and the meeting is a virtual session: virtual meetings make
communication much more difficult. It is bad enough with language barriers and then the tendency
to be more vague to avoid questions, and other techniques identified here; but, with virtual
participation, the body language (over 80% of true communication) is missed and participants don’t
feel the connection. Often virtual participants begin to do other work and are truly just “phoning it
in” for that session.

6. The meeting is scheduled for an hour: most meetings are scheduled in a way that often does not
consider what is to be reviewed. An hour can easily be wasted with meaningless, high-level
discussions. For design details, it is best to isolate a particular area and to set a time appropriate for
that area. 20-40 minutes is recommended due to adult attention span issues. Small groups that
understand the area under discussion (from the business and technical perspective).

7. The content of the design took over 3 weeks to define: there could be a lot of information that
needs to be communicated. Since even an hour can be challenging to allow for attention span,
many meetings may be needed to clarify what the design means. If many people are involved, the
time required will increase which indicates a need for limiting detail or taking other short cuts to get
through the reviews. It is better to review in short increments than to try to complete an entire
design and try to get all of it approved at once. At that point, the detail will likely have difficulty to
get the attention needed.

8. The documentation for the design is not detailed: more and more designs are relegated to user
mock-ups or wire frames with little consideration for the detailed handling of states or data behind
the scenes. If the details are not available, those who implement will make up their own mind and
even greater communication with the business will be required. Expect many changes if review and
update cycles are short. Expect an insurmountable set of changes if review cycles are long and
following significant implementation. Talking about design with little detail in writing, diagrams, or
other representations can be very misleading. Discussions could be endless and this actually causes
individuals to start agreeing to everything, whether right or wrong, just to get out of the meeting.

9. The design individual is a contracted staff member of the implementation vendor: some contract
professionals are highly responsible to get everything right. Some tailor their effort to the vendor
oversight and do what is necessary to get paid. The days where all participants were employees and
where employees were really concerned with corporate performance or reputation are gone. If the
people you are dealing with have less than adequate integrity, you might never know it until it is too
late. Test their ability to make things right to see what you are dealing with.
10. The business users are present; they intend to ensure their requirements would be met with the
design: this condition is generally a great step to take to ensure that the end product will meet
expectations. If this level of understanding is possible, it is more likely in smaller increments and
should be immediately followed by implementation since the gap in understanding between design
and implementation could be wide. Still, business needs and designs may seem aligned when they
are not. The explanations to show how the design will result in delivering the business needs should
take place. This level of discussion becomes, again, burdensome and not possible in a single
meeting for a large design.

In all, you may begin to understand that the level of detail required at implementation level needs to be
crystal clear and validated quickly. The Informed Misperception term was coined for all cases where the
details become a little too burdensome to explain. The design individual will claim to have informed all
parties in the sessions; yet, the level of true understanding was never achieved and the greater detail
with understanding might never have even been attempted. I have yet to see a technology
implementation project where this does not happen.

Continue Reading Part 2

Leon Casaubon Aug 21, 2019Sep 23, 2019

Rethinking Communication in Complex Projects Part 2

Why haven’t the traditional top ten areas of emphasis over the last 25 years resolved the problems
with project success rates?

The depiction below is a compilation of the Chaos study recommendations published over the years.

In 1994, as the first Chaos study was being published, I had 20 years of experience in project
management. I was certified in the Department of Defense (DoD) at the highest level and managed
projects in the billions of dollars. I could not argue that all of the recommendations above were
anything but appropriate at that time. I also could not see how the recommendations could resolve
what I saw was evolving particularly in larger projects. IM was phasing in at the time and accelerated in
the early 2000s when the dot com bubble occurred due to the significant turn away from details and
documentation toward a move fast, try something, break things fast and refactor, and other traits that
pushed the level of engineering to the side for many companies. Once the engineering skills were lost,
then the management layer also failed to understand the level of detail necessary for a system to
succeed and the tendency for IM to be prevalent became closer to rampant.

I still can’t argue against most recent recommendations. A team can implement every one of these
recommendations and still fail dramatically. These recommendations seem targeted at making a lot of
people feel more comfortable while they are failing. None of them are bad and most of them will help
in one way or another, but the product may still be very challenged to meet expectations unless the IM
problem is resolved. Since 2005, I have implemented a personal set of practices to counter the impacts
of IM. I have done this on my own teams and on other vendors’ teams as well. Where the practices
were resisted by other vendors, the projects were still colossal failures. Where the practices were
embraced, the products were successfully deployed and most are still in operation today.

What were the practices to counter IM?

The practices to help counter the effects of IM are focused on clarification and reduction of ambiguity in
any project. Complexity of projects will require greater diligence in using the practices with multiple
teams.

The practices include:

 Keep small teams collocated and increments of progress small.

 Coordinate business agreement with requirements, acceptance criteria and designs prior to
coding.

 Verify code implementation incrementally for business usability to achieve objectives.

When complexity and size become part of the equation, a couple of other practices are essential:

 Leads for teams concurrently develop modular design.

 Use Foundation First principles to ensure each module is in harmony with others for: data
owned and used, communication of state and action, consistent usability, and security.

Review again the top ten recommendations in the section above. Some of these practices might be
considered part of these ten recommendations; however, without being explicit, it is possible to put all
of the recommendations in place without incorporating any of these practices. Management will need
to learn that doing things that tend to make them feel good without seeing the product incrementally
satisfy the business need is just placating behavior. The practices are explained below with greater
detail to enhance use of the practices and to recommend moving away from management placating
behavior to practices that will remove ambiguity and tame complexity focused on delivering business
results.

What are the detailed explanations for the practices to defeat IM?

While detailed explanations follow, it is important to treat these explanations like project requirements
and take them through the same practices to ensure the all users are clear on what is required. We
have to stop acting like communication is perfect and everyone understands what I am communicating,
even when I don’t get to details.

1. Keep small teams collocated and increments of progress small: It is wise to keep teams
collocated. If all disciplines are not possible to collocate, then developers are most important.
The developers should also be full time. Less than full time is highly disruptive to quality of
implementation. You can have multiple small teams, but then ensure that practices 4 and 5 are
incorporated. Increments of progress should also be small. Small is relative. Agile would use a
two-week time box of effort. Shorter would not be appropriate. Longer might be necessary
with a lower competency team that is learning, but I would not recommend anything greater
than four weeks. It is too difficult to perform the other practices at the level of detailed
coordination and level of understanding required to ensure success.

2. Coordinate business agreement with requirements, acceptance criteria and designs prior to
coding: Activity is required to ensure that business requirements indicate what a user needs to
do within the system being implemented to achieve their work objectives. Always clarify each
requirement with acceptance criteria. If you are going to be true to the practice #1, the
requirements also have to be broken down to a level where they could be completed within the
small increment of progress. Then, design documentation for the increment has to be available.
The documentation, at first, can be draft versions that the business agrees could fulfill the
requirement and the team understands sufficiently to implement. Inevitably some of the design
will need to change, but without initial drafts, the likelihood of successful implementation is low.
Every resource would just implement what they believed to be right; however, without
coordination all resources could be implementing in a different way. The design is just enough
to prevent that opportunity to diverge. A more complete design can be done for the as built
capability when complete.

3. Verify code implementation incrementally for business usability to achieve objectives:
Acceptance test needs to occur with each increment at the level for which the acceptance
criteria were defined. It is OK to identify new requirements or criteria for future increments.
Acceptance can be conditional on the aggregation of capability to fulfill the business needs so
that the system would have to eventually be a complete and operational system. Without
incremental acceptance you cannot verify that you are on the correct path and satisfying what
the business needs in pieces. You also cannot give the business the opportunity to continue to
evolve their needs with the implemented system, which is often critical to get to an acceptable
final system. Technical resources should also test and verify that algorithms and business rules
are appropriately applied in these same small increments so that corrections can take place
early and often.

4. Leads for teams concurrently develop modular design: When a system exceeds one small team,
it is best to organize with multiple small teams focused on separate sections or modules for an
application or system. The teams coordinate their internal work and the leads of the teams
meet to ensure the boundaries for sections they own are clear for all other pieces under
development. At the point of integration testing across teams, include the business as well to
ensure the totality of business expectation is clarified for the way the solution works overall.

5. Use Foundation First principles to ensure each module is in harmony with others for: data
owned and used, communication of state and action, consistent usability, and security:
Multiple teams that do not communicate have proven to be a disaster. They key to
communication though is not a set of random meetings where IM takes place. Each team needs
to have boundaries established to prevent the problems that generally occur. Systems often
duplicate data. Only clear definition of which system or module owns responsibility for which
data can avoid this problem. Systems often fail to interoperate. Only clarity surrounding the
means used to coordinate the state of items shared and the sequence of activity where
meaningful can help to control this situation. Usability is in the eye of the users and consistency
requires feedback across teams to help implement business desires. The Americans with
Disabilities Act (ADA) standards need to be applied from the very first screen built so as not to
build a change nightmare for later. Standards can help the most with security; and, sharing
techniques applied in code will maintain consistency throughout an application.

Conclusion:

Improvement focus at a management or project management level is always a good thing to engage in.
Believing that this will improve the level to which technology projects are delivered is significantly
misleading if control is not placed at the communication level of implementation between the business
and implementation team. While the top ten recommendations may make an organization feel better
as they attempt project implementations, the right practices to reduce the most significant problem of
communication are much more essential to success. Informed Misperception is a significant culprit in
technology implementation projects for many reasons. These reasons must be overcome with the right
implementation practices.

Leon Casaubon Mar 21, 2018Aug 20, 2018

Are you Agile, or Fragile?

Many organizations are transitioning to Agile as their preferred lifecycle model for software development. Transitions were directed due to inability for former methods to lead to successful results. After being brought in to help manage a portfolio of projects in several organizations, there were some disturbing trends when using Agile:

Software was delivered, but the users found the software to be unusable.
Consultants developed the software, then left. The organization staff had no idea how to maintain the software.
A number of application projects were completed. Each had a different architecture and set of tools required to build and maintain the application.
Projects were being reported to governance teams with scheduled dates, yet there were no apparent requirements, use cases, user stories, backlog or other lists that might indicate what is being built.
Management was completely at a loss about how to resource projects since many seemed to be ongoing forever without completion.

There were some exceptions; however, the preponderance of software development initiatives that succeeded were very small in scope and constituted a low percentage of overall projects required for customers. There was some information available within the organizations that indicated a process was initiated to convert from a traditional (Waterfall) lifecycle to the Agile lifecycle. Many of the benefits of Agile, however, were not being demonstrated by the activity taking place. What happened?

Myths about the role of the Scrum Master

Myth: The Scrum Master is just another way of saying Project Manager

Not only do both roles do completely different things, but generally a Project Manager has a hierarchical role above the team, something that is not true of a Scrum Master.

Myth: The Scrum Master is the leader of the Scrum Team

The Scrum Master is not a Project Manager and does not have a higher role than the Scrum Team than the rest of the team. This is a common myth that can lead to disaster when adopting Scrum. It is human nature to look for someone to lead a group. Scrum teams are self-managed and decide how they are going to work and what rules (in addition to those imposed by Scrum) will be established.

Previous page 1 2 3 Next page

Information Technology Consulting -- systems integration, custom application development, website and portal design, database design

Category Archives: Project Management Series