Stakeholder Analysis: Importance of identifying, understanding, engaging and managing the players

What is Stakeholder Analysis?

A “Stakeholder” is anyone that is affected by your project or can positively or negatively influence the project. Understanding and appropriately managing all types of stakeholders is crucial to the success of any project.

So... “Stakeholder Analysis” is the process of identifying and engaging stakeholders [with the goal of positive impact].

Usually identifying all stakeholders will result in a long list of people and groups. This list will help your team recognize the true scope and complexity of the pending implementation. Then you categorize the list of stakeholders into various groups; to work on an “Stakeholder Engagement” strategy.

Here is a sample set of stakeholders to consider (for software projects):

• People that is paying for the project.
• Managers that can influence project success.
• People that will have a say on what the outcome/result should be.
• Project members and project roles [Business analysts, solution Architects, QA, Business Owners etc.]
• People that will be using the completed product.
• People that will be supporting the completed product [product support, operations, help-desk, administrators etc.].
• Various capability providers [Hardware, Software, long term licences, maintenance budget].
• Auditors, Regulators and Advisors.
• External Suppliers etc.
• Any trainers that will be training the project team.
• Users that are affected by the proposed solution.
• Others that can influence all above [Internal staff, internal managers, unions, vocal personnel, media, any interest groups etc.].

Stakeholder Analysis Matrix:

It is standard practice to maintain a "Stakeholder Matrix"; to track all identified stakeholders against various stakeholder-attributes and managing strategies.

Below screenshot is a simple sample of stakeholder attributes to track (click to view full image):

Stakeholder Analysis Matrix should look at stakeholder context similar to… Enterprise Role, Project Role, Project/Solution Responsibilities, impact to the project, how project impacts the stakeholder, expectations, engagement plan etc.

Stakeholder Analysis should contribute to [Benefits]:

• Identify all needed roles and responsibilities to build and manage the total lifecycle of the ultimate solution.
• Get a complete understanding of people and needs; that you should be managing and satisfying.
• Creating a more accurate RACI matrix.
• Better understand the true business need.
• Making public the current understanding of who is needed to build and maintain the solution.
• Foster better communication and accountability among project members.
• Better define a fitting solution through engaging all stakeholders.
• Understand hidden risks through engaging all stakeholders.

  

At the end… you will realize that a proper stakeholder analysis has helped you, understand and manage Project’s scope complexities and risks.

To be practical:

• Make sure that the project is doing a “Stakeholder Analysis” [regardless of the size of the projects].
• Make the “Analysis Matrix” visible to all team members.
• Encourage all to poke holes in the current stakeholder-analysis.
• When things go wrong… check what you missed in the stakeholder analysis and improve.

Agile in the Corporate Waterfall

In an earlier post, I explained the basics of “AgileSoftware Development Methodology”, where software products can be built as “successive improving iterations”.

Agile methods seem to have proven/acceptable project success rates. 
But the reality is that the “corporate structure” requires “Waterfall” like thinking; as funding, cost commitment, scope commitment, schedule commitment, labor forecasting, resource allocation, client promises, legal requirements, risk mitigation etc. requires prior planning. Due to these realities and other reasons, many organizations that claim agile are still running hybrid of combined agile and waterfall.

[Waterfall is named.. as the model follows a sequential set of steps to develop software; with steps like Initiation, Analysis, design, Build, Test, Move to Production, Maintain etc.]

Below are some tips on integrating agile into the corporate waterfall culture.

• Accept that the enterprise is thinking in a waterfall manner; for very good reasons. [Executives not only want you to deliver, they also expect you to plan and commit prior to building.]
• Accept that Agile-or-Not, some level of planning is still needed for upfront commitments. [Well... some agile practitioners and corporations may have committed to pure-agile; good for them.]

Model for Agile in a Waterfall corporate

Above diagram separates high level planning processes, from low level agile processes.

Think of current project as implementing a subset of possible product features.

[While waterfall is Project-Centric, agile is more Product-Centric. Scope current project as part of an ongoing product; this project can only tackle what budget allows.]

• Based on requirements, create a list of possible features as “Product Backlog” [What should be in the product someday].
• Prioritize some (must-have and other) features from "Product-Backlog" into current project as budget permits; and call that "Project Backlog".
  [Project’s unfinished items may move back to product-backlog.] 
• Estimate features selected to the project (project-backlog) at a higher level [just like estimating in waterfall].
• Let “Executive View” of the project be around the “project backlog”, “project completed items”, “estimates to project completion” etc.
  [So that... this project is planned and committed to the project-backlog not product-backlog.] 
• Work item flow is to move items from product-backlog to project-backlog to release-backlog to sprint etc.
  [As prioritized items move through release, sprints etc. estimates can be improved… and “Executive Views” can be updated.] 
• Backlog re-prioritization will occur as changes are identified to the current work item collection; then again changes are a part of waterfall too.
  Execute all changes using standard change-process; and update all views as necessary.

Hope this contributes to.... executing your agile project, while painting a planned view to the enterprise.

The line… “Plan with Waterfall, Execute with Agile” is getting traction.

To be practical:

Leave a comment :-)

Software Quality Assurance (QA) checklist

Initial quality of released software contributes to reputation, customer retention, bug/issue fixing cycles and overall cost of ownership. Validating and ensuring “Ultimate Quality” using “Quality Assurance Practices” has become an essential step of development life-cycle.


Think of following as a high level glance at components of a “Successful QA Practice” or a “QA Checklist”... May be even "Designing good Quality in". 
[This is not a guide on how to create individual test cases or a guide on what type of tests to create].

[Start of Project] Setup Core Roles of QA-Practice

Appoint a Test (Quality Assurance) lead; that is responsible for validating an issue free solution.

Appoint a test lead from the design/development team [development team has testing too].

Identify Business-Analysts [that are responsible for defining proper requirements; so, QA can test for expected quality of delivery].

Identify Business Product Owners [that is responsible for articulating the change, confirming the understanding and validating final solution].

Depending on the project, you may also identify various “Subject Matter Experts”; that must contribute to final quality [from both IT and Business].

[This will ensure that there are lead roles responsible for quality form each area (Business/BA/Dev/QA). For very large projects, (for each area) there could be feature-leads reporting to an overall lead.]

[During Project] Core processes needed for solution quality

Identify all stakeholders and a strategy to engage them [part of quality is what they say it is].

Establish a process for requirement gathering and validating gathered requirements.

QA team is responsible for defining tests to validate requirements.

Agree on types of testing to be done by development team [which is different from QA team testing].

Agree on types of testing to be done by QA team.

Agree on types of testing to be done by business [product owners].

Agree on types of testing or validating to be done by identified subject matter experts.

Identify a “User Experience” lead [that is chasing user satisfaction. Such as Documentation, Training, usability etc.]

[You may also identify any tools that will be used for bug/issue recording and trend analysis.]

Business Analyst responsibilities related to Quality

Business Analysts are to clearly document and present Vision, Scope and Requirements.

Understand acceptance criteria [avoid the cost of unnecessary features, development, testing etc.]

Take the time to clearly communicate requirements to designers, developers, testers etc. [Involve non business analysts in client meetings early]

Validate solution against original requirements.

Design/Development Teams Quality related Responsibilities

Solution Architect should identify and maintain an open list of planned deliverable [documents, code, deployment scripts etc.].

Development must test deliverables thoroughly prior to others testing. [Unit Tests – testing individual software components (automating will help testing consistency).] [Integration Testing – making sure complete integrated solution works (automating will help testing consistency).]

Communicate changes in the latest release to QA.

Setup needed testing environments.

Sign off by Design/Development lead; as release is verified.

Test Team Responsibilities

Test lead should create a “Test Plan” for funding and resource assigning (dates, people, locations etc.).

QA team members to define test-cases based on collected requirements [functional and non-functional]. [Collect a list of all feature classes to be testing… all features, deployment, security, usability, accessibility, various platforms, current standard adherence etc.]

Record Bugs/issues and pass it back to development

Provide periodic test status reports

Record known issues that will not be fixed [document any workarounds].

Complete “Requirement Traceability Matrix”

Produce a “Release-Quality” report prior to approval [not all releases are perfect].

Sign off by QA lead.

Test Preparation

Decide on tools needed for testing… install.

Decide a process for bug/issue recording, communication and analysis.

[Development Team] Setup needed test environments

Create test cases and get approval.

Clearly specify test platforms used.

Setup “Requirement Traceability Matrix”.

User Experience

[“Microsoft Solutions Framework” defines a responsibility chain to ensure ultimate user experience]

User experience specialists are to track down all possible user-categories and ensure satisfaction.

User specialists are to chase end-user experience, such as documentation, training, usability etc.

Don’t forget all types of users… operations, help-desk, regulatory, auditors, specific subject-matter-experts etc.

[Business Analysts often play this role]

User Acceptance Testing

Enlist needed business users and get commitment

Assist business in creating test cases

Facilitate UAT

Conduct a post-test survey to gather sentiment

Sign off by business prior to release.

Post Deployment and Quality

Where possible, test system in production.

Record post production bugs/Issues and resolution for later analysis.

Analyze post production bugs/issues for root causes; and implement corrective project lifecycle processes.

[Production-Support should conduct regular meetings to discuss current-production-problems, planning for pending changes (need more system space, need more support staff in six months etc.)].

Help Desk Processes related to continued Quality

Left for you :-)

Various “Development Lifecycle Gates” contributing to final quality

“Vision and Scope” (and charter) review by IT and approval by client.

Report pending change to operations early.

Approve business requirements [IT and Client].

Approve Functional Specification.

Approve Solution Architecture.

Approve planned deliverables [code, solution, documentation, training etc.].

Review [IT] and approve [client] Project Plans [Various Plans including test plan].

“Scope to Solution” comparison by QA and Business Analysts.

IT to validate and approve final development deliverable as “Scope Completed”.

Approval by QA Team.

Business to approve UAT.

IT to approve “Release readiness” of all deliverables.

Client to accept final release and roadmap of next-steps.

Post deployment, verification and approval of “Solution Stability” in production.

All future maintenance funding is planned for [licenses etc.]

Final release to be signed-off by each lead.

Support team to accept product from project team.

Here are some manager type questions [be it a single project or the whole enterprise]

• Who is responsible for quality?
• Are people rewarded for contributing to higher quality?
• What are we doing to educate staff?
• Are there quality measuring/monitoring mechanisms setup?
• Do quality gap findings lead to corrective actions?
• Do we know the cost of running QA processes?  
• Can the cost of QA processes justify the benefits?

Seems like it takes the village to raise Quality.

What is a "User Story"?

Think of a User-Story as another good way to describe a business need.

What makes a user-story special is that user-stories use following accepted format to describe the need in a brief statement.

Accepted format of User-Stories
"As a [Role], I want to [Action]; so that I can achieve [Benefit]"

Above format of user-stories allow us to gather uncluttered insight into the desired actual need. User stories should not include implementation details, as a user-story is simply to state the need and perceived benefit.

Key Features of a User Story

• Everyday business language should be used.
• Not a long elaborated explanation.
• Statement is from the perspective of the user/beneficiary.
• Anticipated Business value (benefit) is very clear.
• May include additional information to reduce the risk of misunderstanding.
  [An additional section may be added to the standard format to state this in detail.]
• May include success/acceptance criteria to reduce the risk of misunderstanding.
  [ An additional section may be added to the standard format to state this in detail.]
• User Stories should not include implementation details.

Sample User-Stories

1. As a student, I want to create my class schedule online; so I can do it from home.
2. As an account manager, I want to receive an email of customer comments; as soon as the comment is logged.
3. As a farther, I want to drop my child to school; so that my child can go to school.
4. As a marketing manager, I need to see our sales compared to industry trends; so I can understand how we are doing.

As you can see from above examples, User stories can be very simple to very complex. Large user-stories may later be broken down to smaller ones.

User-Story flow...

User-Stories should be treated as stated business needs that should be detailed, validated, debated.

Collect User-Story -> verify value -> Validate need -> Discuss alternatives -> Approve User-Story -> Detail analysis -> etc.

Since a given User-Story is somewhat of a work request, a user-story may be adjusted or rejected after details analysis or discussions.

User-Stories and Non-Functional Needs

User-Story format is clearly better suited for expressing functional needs (How a system should function from user perspective). There is much debate around using User-Stories to describe non functional needs. Non-Functional attributes of systems are... behind-the-scene features of systems; such as "must be maintainable", "design to accommodate for future extensions" etc.

Debate is around... if all non-functional requirements can be expressed in User-Story format; and how to estimate and schedule non-functional User-Stories like "Easy to Maintain", "Secure" etc.

For User-Stories adapting to non-functional points are around...
If a certain need cannot be expressed in User-Story format, then at least stay close to the central idea of "a high level brief description of [Benefit] and [Action]". And non-functional requirements being hard to estimate and schedule are not necessary a problem of User-Stories alone... and builders must find a way to deal with these anyways.

User-Stories and Agile Software Development

As user-stories can describe small chunks of implementable functionality (expected from the system), user-stories are now used in agile software development models to define implementable small pieces of work.

In Agile software development, big user stories that can be broken down into smaller user-stories are named Epics. A related collection of user stories are named Themes.

To be Practical

1. Initially treat User Stories as high level actionable statement of need; that needs to be detailed later.
2. Look at the [Benefit] portion of the user story first… see if the stated [Benefit] is valid.
   If the benefit is not valid, no sense in moving forward with the user story.
3. Consider needed [Action] as only a suggested process of achieving the [Benefit]; as there could be better ways of achieving the same .
   Actual mechanism of achieving the [Benefit] can be be finalized during design.
4. If a User-Story is too complicated or difficult to understand, rewrite to be simpler.
   User stories are supposed to be a brief clear statement; not another way of confusing everyone.
5. Set up a user story validation and approval process before building solution based on story.
   Don’t buy into user-stories, just because someone wrote it.
6. Use "User-Stories" as the basis for client communication.
   Stories-completed, stories-pending, story-estimates, planned v actual effort of stories etc.

Pre-Project Work... what happens before the project

Project before the “project”

Good projects don’t just appear… a lot of time and money get spent on creating valuable projects.

By the time a typical project starts, there usually is an approved piece of work to be delivered; with clear goals and funding to start the project.

Pre-Project work goes by many names

There are many activities that contribute to the final definition of a project.

This work that happens prior to starting a project goes by many names… Pre-Project Analysis, Preliminary Investigation, Feasibility Study, ROI Justification, Project Opportunity Definition, Project Approval Work, Strategic Alignment Work, Business Case Approval etc.

“International Institute of Business Analysts” (IIBA) call this pre-project stage “Enterprise Analysis”… as in analyzing the enterprise to define needed new work (project), to fill current gaps in Enterprise Capability List.


"IIBA's Enterprise Analysis Knowledge Area describes the business analysis activities necessary to identify a business need, problem, or opportunity; define the nature of a solution that meets that need, and justify the investment necessary to deliver that solution. Enterprise analysis is often the starting point for initiating a new project. Outputs provide context to requirements analysis. Solution-Scope and Business-Case is also used as input for project charter."

Shorter version of Project Approval…

Define Business Need > Define Needed Functionality > Build a Business Case (or justify) > Get $$$ > Start Project

"Sometimes this shorter process could happen over a single conversation. For an example… your boss says that finance needs a way to track work… you suggest an electronic-list that takes two days to implement… boss agrees and asks you to do it."

Process of justifying Bigger Projects...

Bigger the project gets, more you need to justify the investment needed to deliver solution.

You will have to specify the pressing need for the project to secure money.

IIBA calls this work to get to identify and justify the project, “Enterprise Analysis”… and suggests a process for Enterprise Analysis”.

Overview of IIBA “Enterprise Analysis” process goes like this..

1.  First define the Business Need.
   (You will have to gather business need(s)… document… verify with many others… and then get approval for the stated-need etc.).
2.  Then determine if the enterprise currently has no way of satisfying this need… so you can identify the gap.
   (Before you plan on building a new-something to solve the problem… you should look in the enterprise to see if there already is a way to solve this problem).
3.  Then determine the "Nature" of the solution and the mechanism of getting to the solution.
   (Talk to solution (technical) experts… and come up with a high level plan of creating something new (application, process etc.) to solve this approved-need.)
4.  Determine the scope of the proposed solution based on the determined need.
   (Scope the solution well… this will help you in estimating-cost and communicating expected solution to managers and to eventual project team.)
5.  Build a business case for the “defined scope and approach” to satisfy the stated Business Need.
   (Now that you have defined a clearly-scoped solution idea for a validated and approved business need… you can build a “business case”; to get the project approved)
   It is very important to understand... that at this stage, you may not have a defined solution; but the loose idea of the solution you are looking for. So, any estimate of effort/money associated at this time is only a guess. Project is suppose to clearly define estimates of effort/money after detailed analysis and planning.
   ***Business Case may also include a ROI justification.

Here is quick diagram “IIBA Enterprise Analysis” process (see BABOK for exacts).

To be practical

1. Recognize that effort is needed to define a project (or a piece of work) of value.
   That defining a project is not just a "project management" related activity.
2. Assign someone (business-analyst) to document the stated-need and get approval.
3. Get the business-manager (or whoever has the problem) to approve the need and stand by it. 
4.  Don’t forget to talk to the right solution experts (implementation SMEs) to look at possible solutions.
5. Validate solution fit with other technical experts and business. 
6. Scope expected solution as much as possible; so that there is no miscommunication.
   Clear scope will also help in identifying scope creep later in the project.
   State current assumptions and constraints too.
7. Create a business-case based on approved need, missing capability, planned solution approach and defined solution scope... so that it is clear why we want to do what we planning on doing.
8. Don't forget to include paperwork justifying "Return on Investment".
   Remember that you are competing for the same funds. Better Business-Case wins.
9. Understand that... at the time of creating a business case, any estimates of effort/money is guesswork. Later, the project is expected to be doing the needed work to solidify estimates.
   [Project is approved... because it makes business sense and seems reasonable. Project is supposed to be coming back with more specific cost estimates after planning; with better estimates based on a better defined solution; which gives the sponsors the option of funding the build or kill.]

A Checklist for software support teams.... for accepting completed software projects

Software Maintenance Acceptance Checklist
Assumption is that... software project-teams should handover scope-completed-solutions to long-term-support-teams; so support-teams can take over solution-upkeep from that point. Ongoing upkeep would include planned-maintenance-activities, bug-fixes, new-enhancements, ongoing –customer-support etc.
  

Project teams are expected to leave behind a stable, scope-completed product release. But, the problem is that... project teams often sneakily leave a chuck of unfinished work for the long-term-support-team to work on.
  

This is a checklist… to assist support-teams; when accepting software projects. Show this to the project manager as early as possible; so that the project can prepare for this checklist.

[This is not a project-closing-checklist to assist project teams. This is a product acceptance checklist for maintenance teams; so that maintenance teams can evaluate what they are accepting] 

Maintenance Acceptance Checklist

Check Description
Initial Checks
Maintenance roles and individuals identified and documented. Lots of projects start without paying attention to a long term support needs. Force the project to identify support personnel and budget. Project should identify roles and individuals needed to support the system after the project (from IT, Business, Vendor etc.). Also, make sure the business owners understand their ownership responsibilities. [sample support roles: IT manager of product, operations staff, help desk, issue resolution and bug fixing, business administrators and super users, business owner of product, how long will the original project team will be able to answer questions, vendor support etc.]
All need artifact repositories are defined. Projects should have defined repositories for documentation, code, training material etc. This is to ensure that project is not planning on transferring an unorganized, half done set of deliverables.
Maintenance team is allocated enough time for training. Make sure that the new team is actually allocated enough time to get trained on this new product. Allocate time for training... not just accept the product last minute.
Project Development Lifecycle related checks
Project Vision/Scope/Business Need/Success criteria is clearly documented and signed off by sponsors. Project should have been created to accomplish certain goals. Project should have documented these objectives and received approval from sponsors. A clear understanding of these original objectives are important, when further enhancing the solution or answering ongoing business questions. Is the project charter still valid?
All Stakeholders are clearly identified. Make sure you get a decent stakeholder analysis. So you know who all the players are and how they were engaged. This knowledge sometimes does not get transferred out of project teams. Get a good understanding of who is business, IT and vendor that are playing a part in the success of this product.
Business Analysis Documentation is complete. Project “Requirements” should be clearly documented; so, the support team can continue with the original understanding.
Testing related documentation is complete. Project should have various testing documents. Procedures and test-cases to test a new release, test-cases for a quick smoke test etc.
Requirement Traceability Matrix (RTM) is complete. Project should have a mechanism to map requirements to provided functionality.
All required environments are available.  Make sure the project gives all needed environments (development, test, training etc.) to continue supporting the solution. If not, you will be spending time and money… either putting together environments or inventing work-around processes.
Training and training documentation completed Make sure the project has completed all training (users, helpdesk etc.) and transition management. If not more effort to do that.
Relevant service levels are understood and signed off by business and other stakeholders. Business needs to understand the agreed support level; downtime, recovery time, recovery point, planned maintenance windows etc. Other relevant teams (network etc.) need to understand their commitment to the solution health.
Customer roles and responsibilities are defined and understood by customer. Customers and business managers sometimes do not understand their ongoing commitment to the product.
Vendor related items are documented and handed over. Are there any vendor contracts, commitments, contact #s.
All required licenses are understood and procured by project. Many projects create a solution forget the licenses needed for post project development-tools, business-user-connectivity etc. [Licenses like… Hardware, software, application CALs, database CALs, third party software, annual-maintenance-charges etc. for all environments])
Solution in Production Related Checks
Solution is stable in production. Many new deployments are not stable; and maintenance-teams unofficially end-up putting extra unplanned hours stabilizing the solution. It is good to officially identify the effort needed to fix the problems projects leave behind. Is the system stable under full load?
Application monitoring (reports, logs, start system, stop system, verify system health etc.) tools are complete. Can the application be monitored?
Common support procedures accepted by maintenance team. If the project has not documented these, you will end up doing the work eventually.
Further change-deployment-process is clearly documented and accepted by maintenance. Maintenance team needs to understand how to properly push new releases to production. Make sure the process is clearly documented.
Disaster recovery and redeployment is clearly tested and documented. Need to understand how/when/point to recover the system in a disaster.
Business continuity plans and procedures are identified. What is the plan, if the system is not available for two days?
Production issue resolution and escalation process is defined. Need a clear process to handle/escalate issues.
“Customer Support/Service” process is well defined. Is the process of listening to the customer and providing appropriate feedback defined?
"Expected-Maintenance-Activity List" completed and accepted. Project should build a planned-maintenance-activity list. This list states what activities, agreed service-level and effort that is needed for future upkeep of the product. This should be the actual tasks and effort expected from the support-teams to maintain the product… so you can later compare this baseline estimates to reality.
Official Unfinished Work
Pending risks accepted by Maintenance team. Maintenance team should understand all “identified risks”; so that the team can plan for downside.
Pending Issues accepted by maintenance team. Maintenance-team should understand pending project issues that are not resolved. Because you are on the hook to resolve them.
Known bugs are understood and accepted by maintenance team. Get a grip on current bugs. You will have to either fix these soon... or provide work around processes. If there are too many bugs, complain like there is no tomorrow.
Road Map of next steps accepted by sponsors, customer and maintenance. Projects often leave behind a secret list of promised future enhancements. Make sure everybody understand what that list is.
“Benefit Realization Review” process is clear. Are there reviews that need to be done to evaluate the project success in 6 months etc. Who is supposed to be doing them?
Project Team Sign-Offs (appoint leads as assessors of their areas)
Project Manager has signed off on project solution quality. Get the project manager to officially say that the project is ready to be transferred to the support team.
Business Analyst Lead (Product Management) signed off. Get the lead of the business analyst side (whatever it is called in the project) lead to sign off that the solution actually satisfies the business need.
Development lead signed off. Development lead is responsible for quality of all development artifacts.
Test Lead signed off. Test (Quality Assurance) is ultimately responsible for signing off a working product..
... Based on the project, follow all leads for official sign off. Lead of Architecture, Security, Training, if there is a user-experience group etc.
Final Checks
Solution accepted (signed off) by customer. Make sure the customer is actually happy with the solution as scope complete. If not, more unplanned work for you.
Solution accepted by other relevant IT teams. If there are other relevant IT teams, make sure they all have accepted the solution (Help desk, Network team, Security team, Architecture etc.). Team list may depend on the project type.
All “Personnel and Budget” needed to maintain the new product is determined (and approved). To not take ownership of yet another product without a proper funding plan.
Maintenance-team trained and ready to accept the new system. Someone from maintenance should Sign off that the maintenance team actually got trained.
Maintenance-team have no issues or concerns. After training, maintenance team still may have concerns. List them with effort needed to address them.
Final versions of all project collateral accepted by maintenance team. Make sure that the maintenance-tem is happy with all needed supporting components (documentation, source control, deployment scripts, proper business introductions, service-level-agreements, disaster-recovery-plans etc.).
Sign-off this document. Get a manager to sign off that this list is actually accurate.

All this is… so that maintenance teams will not end up having to complete a half-built solution. And for management to understand that project-team actually left a product not fully completed.


To be practical…

1. Create your version of the “maintenance acceptance checklist”.
2. Show the list to project managers early… so they know what your support acceptance criteria is.
3. Identify the core support team early, and try to embed some in the project; as support quality control.
4. Actually follow through completing and signing off of the list.
5. Identify area leads (activity or feature) in the project, and appoint them as assessors of that activity. Get them to sign off their area. This will put validation responsibility back on the project.
6. Even if you are forced to accept some incomplete line items for practical or political reasons, a list will bring attention to incomplete line items... as “additional-effort-needed” by maintenance-team.
7. Do this, even if most people from the project team are assigned to maintain solution; to ensure a quality project completion.
8. Monitor and compare planned-maintenance-activity list (provided by project) against the actual activity and effort the support teams have put in. This will help improve future support effort estimating.

"Agile Software Development Methodology" for Laymen

Everybody is talking this “Agile Software Development” thing. Following is to explain the basics.

Skyscrapers and waterfalls

First, let’s see what non-agile is supposed to be. Skyscrapers have to be well planned and designed before start building. This is because, it is big trouble to change design-plans midway. It is not very cost effective to change the base holding-structure after building five floors. This pattern of designing before building is true for many types of projects; like building bridges or building cars. These projects go through some activities like plan, design, prototype, validate, get customer approval… and then start building. In the software development world, this way of doing projects in sequential stages (like analyze, plan, design, build, test, deploy etc.) is known as the “waterfall method”; as activities flow one after the other. Traditionally, when software developers got a problem to solve; they analyzed the problem, designed a solution, built it, and then delivered the promised product to the customer (some named it waterfall methodology).

Typewriters and waterfalls

Twenty years ago… typing documents using type-writers were a well-planned activity too. Documents needed to be well planned on paper before actual typing started, because the tool did not allow us to shift paragraphs or insert new sections midway.

Modern word-processing software goes flexible

Today’s current word processors allow us to start typing a document without any plans. We know that the software allows us to change anything with ease. So… current word processors allow us to be very “agile” (or nimble) in the process of creating documents. We can start typing, show a first draft to the boss, incrementally improve the document based on feedback etc. We do not complain that the documents are difficult to change after typing or not having needed skills operate the tool.

Software development tools go flexible too

“Software Development Tools” also started to get matured like the “Word Processing Software”. Process of implementing changes (or enhancements) started becoming easier. In other words, allowed us to be more “Agile” in building software.

Gist of the above explanation is that… at the heart of “Agile” is the ability of modern-software-development-tools to implement changes with little effort. And the developers itself be well trained in the process implementing changes; using the tool at hand.

So this idea that “software development tools allow us to implement changes at will” caught on… that the tools now allow us to embed designing and planning into actual building.

Now we can just start building… show output to customer… get feedback… implement changes… refine the output… add new pieces. Keep on showing the incremental results over and over again to the customer till the customer is happy. Then… why don’t we bring the customer into the development team too; to direct the development-process-outcome itself as it is being built (no major upfront planning needed, let’s change as see fit). Then they thought… if the customer is sitting with the development team, maybe we don’t have to create unnecessary intermediate design documents to get customer approval too; as we can show the solution result itself easily (instead of first designing on paper, let’s show the actual working product; then change based on feedback). This could make the Software-development-process more efficient too.

The idea that the most important deliverable in software development is the solution; and all other effort is to support this outcome.

In other words…. today’s software development tools now allow us to start building from day one (at minimal cost to fix mistakes or change direction), solution visibility from day one, customer feedback early; on delivery direction and value. Feedback based enhancements… thoughts went on.

Then… some smart people got together in 2001 at a ski resort in Utah… and formalized this “Agile” idea; and called it “Agile Manifesto” (http://agilemanifesto.org).

Today… there are many formal methodologies that are claiming to be agile oriented (Extreme Programming, Scrum etc.). “Agile Development” has become an umbrella-term to cover many methodologies that are based on ideas like “Non waterfall”, “build in small cycles” , “iterative output”, “embrace change”, “let owners see results and request changes”, “let owners add enhancements during build” etc.

What we should not forget is that for agile to work well; the basics are…

1.  Tools should allow for easy rapid changes.
   Keep in mind that not all software development tools are created equal…. Pick tools that are better suited for non-planned changes. 
   Today’s software tools are good, but not magical enough to allow any mid-cycle change with no effort.
2. People should have needed skills to… use the tools to accommodate rapid changes.
   If not, you will start hearing statements like… “this is a big change”, “that change will take a lot of time”, “I have to re-engineer more than a few existing modules to do this change”.
3. Even if the “agile” model thrives on “change”… lesser the changes needed the better it is.
   A bit of planning, designing or thinking-ahead at the right time will go a long way in pointing in the right direction.
   straight path to the solution is more cost effective than zigzagging without a plan. 
   Plan ahead a bit, as effort needed for some changes could be more than you bargained for.
   Plan ahead a bit, as some drastic mid-cycle changes could cause more pain than value.
4. Common sense and sound experience beats it all…
   Agile methodology may work better for certain projects. Agile methodology may work better in certain stages of a given project etc.
   Incorporate heavier upfront analysis or design when the need is obvious.

One day far in the future… when skyscrapers are built using easily re-configurable tiny cubes… skyscraper engineers too will be arguing about agile-scraping. 

Some Agile Development Methodology related myths

1. Agile only means no unnecessary documentation needed.a) Need documents to handover to other teams.b) Need documents for Training new employees. c) Initial developers may move on or forget eventually.d) Regulatory or Approval requirement may call for documents.
   e) Most importantly, when something goes wrong after two years… and your boss wants to show the design to other bosses, if you do not have pretty design documents, you are in trouble.
2. Agile does not need architecture or design. Planning with experience will set the direction to minimize changes; and improve solution value.
3. Agile is only for small projects.
   There are many examples of successful large agile projects in the real world.
   
4.  In Agile… effort needed, time needed and the outcome itself… is unknown; as the end is not planned for in the beginning.
   This totally depends on your approach, how much to plan upfront.
   In a regular project… upfront planning will help you identify big buckets and estimates. Then you will be able to identify and adjust for scope-creep or unexpected.

Question

What if there is a project that is to be delivered in 6 months; and final solution qualities are well defined and understood.

Will design and build the solution in a “waterfall method” be better than using “Agile Method”?

[Argument is that… why bother with iterative, multi-cycle development… when we can do it in one cycle; as the needed exact outcome is known upfront]

Software development and the Ferrari

Background

Corporate Bob occasionally delivers small parcels to satellite offices; and requested a permanent delivery solution from “Practical Solutions Department”.
“Practical Solutions” sent a business analyst to meet with Bob, so a proper solution can be provided.
Bob said… “Small packages, but speed is of importance; as these usually are legal documents to be signed as soon as possible”.
To meet Bob’s stated requirements… two fast Ferraris (second as a backup) were purchased later that month.

Problem

Now, what in the world is wrong with this scenario; Ferraris to deliver parcels.

Well for starters, a much cheaper car (or two) would have solved the problem too. 

But on the flip side, some may argue that the seconds-saved over a cheaper car is invaluable too.

Question is… 

How do we ensure that an optimal (whatever “optimal” means) solution is delivered? Not a product or service that is over engineered.

Analysis

Businesses constantly over engineer solutions… and there no proper gates or understanding to verify right fit.

To be practical… here are some potential options

1. Always have a clear Vision/Scope statement; that is visible to all stakeholders.
   If you do not understand the original need, then you will not be able to understand if the solution is the right fit or not.
   By having the original purpose visible, we are hoping that somebody will start asking the crazy questions about the proposed solution.
    
2. Stakeholder analysis: Identify stakeholders upfront. What each stakeholder role is and how to engage them.
   Recognizing and Publishing a stakeholder list will help identify the authority on various requirements.
   Knowing who has the final call will help in clearing noise… and in validating conflicting requirements.
   Stakeholder analysis will also stop random managers from requesting unintended features.
    
3. Publish both raw-requirements and final-validated-requirements.
   Somebody will see errors in requirement interpretation.
    
4. Make sure the business analyst actually understands true business needs; as opposed to what business said.
   If business analyst is not the business expert, then add a subject matter expert to work with the analyst.
   Business analyst is to represent true business needs to engineering… and to fight off crazy solution proposals from engineering.
    
5. Investigate possible alternative solutions just for fun.
   Compare why the proposed solution is better than the other options. Write down comparison results for all to see.
   Come up with simple alternatives too… take a taxi, fax documents, use paper etc.
    
6. Identify all costs that will take to maintain the solution over the years.
   (Licensing, installation, training, maintenance etc.)
   Don’t forget the long term support needs. Many projects concentrate mainly on delivering the solution… not on supporting activities, who and cost.
    
7. Maintain an open feedback-list or a discussion forum.
   This will surface all concerns that get swept under the rug.
    
8. Keep in mind that simplicity is still the king.
   If the solution cannot be explained in layman’s terms (conceptual design), that is the root of all Ferraris.