Project Management Best Practices

Leading a project to successful closure requires right combination of skills, experience and confidence. Here are some guiding principles to execute projects smoothly :

Why Adopt Best Practices?

•          We want to deliver the right solution within defined timelines
•          We want to Identify problem areas at an early stage and take corrective actions
•          We want to bring efficiency, effectiveness, standardization, and predictability to our delivery model

  Best Practice: Adopt the Agile Mindset

• Create an enabling environment & empower your team members to work independently with responsibility & ownership
•  Promote upfront, open communication
• Best output can be achieved only when people enjoy what they are doing , help them understand the value of their work
• Any process which does not add value to project needs to be re-evaluated
• Believe in incremental evolution: to build a perfect artifact it may have to go through several iterations

  Best Practice: Understand your project Objective

• What is the main objective of the project? What are the key success criteria for Business?
• What are the current pain points /challenges business is struggling with and how is this project going to help overcome those challenges?
•  How does this project deliverable fit into the Business Road map?

Examples for some of the drivers for your project :

·         Competitive edge, rich user interface, rich content, quick & easy maintenance of site, real time content updates

  Best Practice: Define your Constraints / Risks

• Do you see a gap in requirements understanding?
• Do you need to deliver in a squeezed timeline?  Example: Business demands "Go live" within next 4 months
• Is your team geographically distributed? Are there any challenges within teams? Dependencies within teams. Example: Design team onshore and tech team offshore
•  Are there any third-party dependencies?  Example: integrations like social plugins, sales force, loyalty, etc
• Do you have the right team structure for each track of activity?  Example: Enough QA, design strength
•  Are there any activities that are beyond your scope but are going to affect you?  Example: Content population, translation, data migration

  Best Practice: Plan Upfront

Plan for the following upfront :

• What are your high-level timelines? How are you going to divide the work in iterations?  
• What are the roles and responsibilities of each team member? What are the external dependencies?  
• How do you plan to communicate with different stakeholders
• What are the tools that you are going to use and for what purpose?  Eg: tools for tracking, bug management, requirement management, project planning, etc
• What are the activities that can be automated?  eg: Quality check, deployment, performance analysis, etc
• What best processes and engineering practices can you implement to bring efficiency to the team?
• What are the environments you will require for your project execution and when? eg: dev, qa, prod, staging, etc
• How are you going to track and report progress? 
• How will you manage RAID? 
• How will the scope be managed? 
• How will you track Quality and defects 
• How will your user stories flow from inception to completion 
• Team Ramp up planning 
• Team Building, Feedback & Appreciation Framework  

  Best Practice: Define Checkpoints at every stage

<<Coming Soon >>

  Best Practice: Lookout for warning signs

Lookout for potential problem areas. The earlier the problems are detected the easier it is to manage them.

Warning signs may include :

•          A small variance in schedule or budget starts to get bigger, especially early in the project
•          You discover that activities you think have already been completed are still being worked on
•          You need to rely on unscheduled overtime to hit the deadlines, especially early in the project.
•          Deliverable quality or service quality starts to deteriorate
•          Approvals for deliverable not received on time can impact ongoing work

  Best Practice: Define the Review Process

Identify SME for each track and ensure that the following activities are reviewed & improved at appropriate times:

•          Requirement definition / Story definition
•  Ensure that the quality of the story is good. It captures all the information required. Does it specify Acceptance criteria clearly? is it calling out Dependencies or integration Details?
• Review by senior BA, Tech Team for quality of the story
•  Review by Product owner
•          Visual Designs ( UX /VD)
•          Review to ensure technical feasibility & conformity with development standards
•          Review by Senior Designer for quality of work
•          Review and approval By the client before it's passed on to the development team
•          System Architecture & Design
•          Review by Senior Architect
•          Review & Approval by Client
•          QA Activities - Test Cases, Defect Descriptions
•          Review of strategy by QA Manager
•          Review by the QA Manager for each Sprint
•          Is our QA Plan covering all areas: functional, regression, creative, usability, etc
•          Development
•          Code Review by Architect for each Sprint
•          Automation of Code review if possible
•          Coding Guidelines: review by Senior Architect
•          Functional review by BA for each sprint
•          QA review during development to identify gaps upfront
•          Creative Review by the Design team for each Sprint
•          Full Regression testing ( For all scopes delivered to date ): preferably Automat it
•          Build & Release process
•          Review the Release process for efficiency
•          Review if we have clearly defined branching & merging strategy

  Best Practice: Project Tracking

Develop Metrics to cover the following for each sprint :

·          

·          

·         Total Estimated effort VS total burned effort VS total effort required: this will help you predict

·         Number of defects in each sprint: Area of defects: functional, UI, Code review, etc

These metrics will help in doing objective progress checks

  Best Practice: Do Retrospective & improvise

A Retrospective should be done after each iteration to identify

•          Improvements in processes
•          Technical Improvements/learnings
•          Improvement in testing
•          Communication & Planning

These should be used as a guiding principle to improve for future sprints. Also, these learnings should be passed back at the organizational level for broader benefits.

Myths about Agile

Myth #1: Agile = Scrum

What’s the first thing you think of when you hear the word agile? For many of us it’s a daily stand up meeting. Or maybe it’s creating a backlog of user stories that get delivered in a two-week sprint. Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles. Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-Driven Development and Xtreme Programming). Simply “doing Scrum” doesn’t mean you’re practicing agile management.

Myth #2: Anything can be changed anytime

Adopting Agile does not imply that anything can be changed anytime. It also does not imply that changes can be done without impact analysis or without planning.

Adopting agile only means we accept that fact that changes are part of life. We are open to changes and we are skilled to handle changes in efficient way.  We still need to time the changes , we still need to plan and we still need to do impact analysis.

Myth #3: Agile Doesn’t Believe in Documentation

It’s true that the Agile Manifesto values “working software over comprehensive documentation” However, this doesn’t mean documentation has no place in agile processes.

Documentation is done only when it adds value to the project or business.

Big and lengthy documents are replaced by minimum viable information that needs to be capture. Also there is a big stress on how documents can be prepared in collaborative way, shared easily and can be continually improved.

Myth #4: Agile Development Does not scale

In general, software development itself has scaling issues. This is clearly not a methodology-specific problem.

Large Scope implies greater probability for failure

Greater the team size, the greater the communication risk and complexity.

Agile development simply accepts these realities and recommends smaller projects, shorter delivery time frames and smaller teams.

This does not mean organizations should avoid solving large problems. Agile simply suggests that there is a different approach to solving the same problems. Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects staffed by smaller, cross-functional teams. The various teams’ work is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility. There are clearly other processes that need to be instituted in order to facilitate communication, integration, architectural design and standards and decision-making amongst the teams

Myth #5: Agile Doesn’t Need Project Managers

Agile project involves as much planning as any other project and for that project managers are required.

The only difference is that agile project managers won’t be telling people what to do or when to do it. That’s because agile methodologies value self-managing teams—whose success relies on collaboration, localized decision making, regular communication and tools for visualizing and sharing work in process.

Myth #6: Agile Only Works for Developers/Software

Agile is a change in mindset. It about changing the way you thinking. Agile is about breaking down work into smaller steps having independent value. This can be adopted in any domain. This can be adopted as way of life.

Myth #7: Agile Will Fix All Our Problems

A single methodology cannot fix all the problems. It helps in improving your way of working. 

How to write a good User Story

User stories are the most popular technique in Agile to capture requirements.

While writing user stories is easy, ensuring that they are effective and to the point requires diligent effort.

What is a user story

A user story describes how a user is going to use the system. It capture's user prospective.

The format of a typical user story is 

As <persona> ,

I want <what?>

so that <why?>

Example : As a student, I want to purchase parking pass, so that I can drive to school

Epic

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be dis aggregated into smaller user stories at some point

Theme

A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing.

Themes are often used to organize stories into releases or to organize them so that various sub teams can work on them.

Elements of a user story

A user story should at minimum have a title. Other good to have elements can be

Description: More detailed description

Acceptance criteria/ Steps to validate   : To ensure the working software meets the requirements of the story
Integration : If the story is about integration with some outside entity
Assumptions : If there were any assumptions made for development of this story
Risks : Are there any risks associated with this story
Design Considerations : What are the design elements to take care of

How to Write It

Step 1 : Identify User Types

A user story describes how a user is going to use the product. So the first step is identify different types of user.

For example an online ticket booking site can have following types of user:

1 An administrator to manage users

2 An administrator to upload to data against which booking can be made

3 A customer of site who would like to book the ticket

4 An sales executing who would like to see reports as to how customers are using the site and what the revenue areas are

5 A Customer care executive to track that customers using the system are not facing any problems.

Step 2: Define Personas

Based on user types identified in step 1 , user personas should be defined. These are distinct roles for which product would be build. All the user stories would cater to requirements of at least one of these personas.

Step 3: Write one liner titles for all use cases you could come up with

Step 4 : Write additional information about user stories like description, validation steps etc.

Step 5 : Repeat the process to identify any missing stories.

How to make sure that it’s effective

Implement INVEST to write good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

· Independent

· Negotiable

· Valuable

· Estimable

· Small

· Testable

Let’s look at details of each of these items: 

Independent:  Stories should be as independent as possible.   In other words, stories can be worked on in any order.  

Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotiation between the customer, developer and tester (at a minimum).  The goal is to meet customer needs.

Valuable:  If a story does not add any value to the system, it should not be done. User stories are prioritized in the backlog according to business value. Business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  If that is the case we should consider splitting the story to gain more clarity. Sometimes even splitting a story doesn’t help. If this situation occurs it may be necessary to do some research about the story first.  

Small:  Stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used. Ideally a user stories should not be on average more than 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  

Testable:  Every story needs to be testable in order to be “done”.  Acceptance criteria should be written with user stories in order to define done state.   

Agile for Fixed Scope Projects

Today  majority of product development organizations have adopted Agile based development approach . It helps them develop products incrementally. This in turn helps in  prioritizing as the business model develops and adaptability to change. The scope is also incrementally updated in such cases. This is really helpful in cases where development needs to adapt to the changing business priorities.

I recently came across cases where budget is fixed and there is a need to complete the development within the defined scope. How can agile development help in those cases ? Should such projects follow normal waterfall approach or will there be benefit in still adopting agile model.

Here are some agile practices that can be adopted

• Incremental development where outcome of each iteration should be complete and verifiable
• Daily Stand up call within the team members to discuss task for today and obstacle that the team is facing
• Regular interaction between project team and business representative 
• There are some Engineering practices which can be beneficial as well
• Continues Build and Deployment
• Automation Testing
• Pair programming
• Test First Approach

These practices can benefit the client, the team and the management equally .

Benefits for Clients/ Business Stakeholders :

• This model gives a clear visibility about the progress and a chance to review outcome iterativly
• It provides reassurance in form of conformance to deadlines and also gives ability for course correction

Benefits for Team:

• Team gets regular feedback which helps in identifying gaps in requirement understanding
• Regular deliverable adds to the satisfaction level of the team because of feeling  of achievement
• Interaction between team members creates healthy work environment and enhances communication

Benefits for Management:

• Deliverable produced after the end of each iteration acts as  milestones for the project and enable clear tracking
• Ability to showcase the output gives greater chances of building good reputation with the client
• Happier and satisfied team results in low attrition rate
• Enhanced communication in the team helps in reducing confusions and hence lesser wastage of time

Requirement gathering - Thinking beyond functionality

Continuing from my last post about non functional requirements , here are some more pointers to consider while designing architecture of a software product.

These are mostly relevant for a SaaS based product targeted at wide variety of locations and audience.

These points need to accounted not only for design but also for testing:

1. Scalability : How will the product scale 
1. To different screen sizes : This involves a sound design strategy on how different parts of the screens will scale up or down based on the resolution and screen size of user. The key is to ensure that the usability and readability aspect is maintained at all variations. 
2. To different browsers : This is very important aspect that architects and designers need to be aware of from the very beginning. It is important to understand and analyse compatibility across browsers before deciding on client side components to be used for development.
3. To different platforms : Web, Mobile , OS etc
2. Handling date and time zone: If the users are going to be in different time zones then how date formats and timings are going to be handled. Here are some important aspects to consider :
• Date Time Format : 
• Fixed format for all
• Provide users with the flexibility of choosing format
• Pick a format based on user location and give ability to customize.  
• Activity Timings :  Normally activity log is maintained for all the activities performed by a user. These logs are used to show activity history in various forms. While the events are saved in database using a standard time zone , we might want to show the time to user based on his or her time zone.
• Scheduling :  Some products allow users to set up reminders and notifications. These notification need to trigger based on user' time selection and user time zone. 
3. User Types & Permissions:  Its important to identify few key User roles of the system and also the set of permission each type of role will have. We may want to group users using user groups. We may want to create an administrative interface to modify permissions given to a role. Based on the permission granted to the user , we will have to filter out the options available to the user. We may also want to filter data that is visible to a user. Also each user may have a different home screen based on the role and some parts of the system may be completely invisible.
4. Delete Operation : Following points are worth considering before finalizing any solution:
• Soft Delete Vs Hard Delete :  Delete operation can be performed in two ways. Soft delete which is just marking the data as deleted but leaving it in database and Hard Delete : which is physically deleting the data. Hard delete can be combined with archiving strategies.
• What happens to search ability of data which is soft deleted? How will the references to deleted data show up? What happens to the logs ?
5. Concurrency : How the system will respond if more that one user are trying to update same data? There are basically two important strategies : either lock the data which is being updated by one user or adopt the strategy of what ever was last saved would be the latest update.
6. Integration : Are there any integration requirements with other systems e.g integration with payment gateway, integration with user management systems, video streaming systems etc
7. Customization : Does the system support customization for different users. Customization can be enabled at various aspects:
• Color schemes : How various elements of system will be displayed.
• Home screen/ Dashboard : What will the user view on the landing screen after login
• Feature Labeling : Some features can be labeled differently for users of different domains as per industry standards of the domain.
8. User Account Management : Does the system support integration of login with other popular apps like facebook, linkedin, google etc.

Non Functional Requirements Checklist

Here is a Check list of non functional aspects of a software system. These also needs to be planned for along with all the features.
This is a very general checklist and can be customized with exact expectations for the products.
The last two columns can be used to record expectations and criticality.

Category	Description	Expectations	Criticality
Capacity & Space	Number of concurrent users
	Number of transactions processed per hour
	Growth Requirement ( Users , Space, Transactions)
	Maximum File storage space allowed  for each user/company ???
	Minimum free Memory required to be available on server all the time
Response Time	Login to the system
	Loading a  screen with single record
	Loading a screen with Multiple Records ( Grid View)
	For Add/Edit a single record
	Batch update Operations
	Search  a record
	Export with records --- 20
	Import with records --- 20
	Upload File of size ---500 mb
	Upload File of size ---
	Download of file of size ---
	Download of file of size ---
	Reports
	Log Reports
Scalability	Hardware scalability
	Vertical Scalability - Can the Site be replicated to multiple locations for catering to increasing user base
Data Archiving	What is the limit after which data in key tables should be archived
	What is the criteria for identifying data to be archived
Portability	Browser Supported -
	OS Supported ( for client installable App) ---
	Minimum System configuration ---
	Memory Space required for Installation( for client installable App) --
Install ability ( for client installable App)	Ease of Installation
	Version upgrade process
	Expected frequency of version upgrades
Audit ability	Who visited a Web page
	Who read or updated a database
	Who read or updated a program
	What operations were performed
Robustness	Error Handling
	Exception Handling
Interface	With Email Client
	Any Payment gateways
	Support import/Export format of some other system
	Any accounting system
Availability	System Up Time
	Defined Maintenance window
Data Backup Policy	On what frequency data ( database +Files) should be backed up
	Data backup location ( for disaster recovery process)
Security	Security of servers
	Security of Files in server
	Security of Database server
	Security of records in database
	Security during data transmission
	Data Privacy
	Encryption policies

Here is another of my post about non functional requirements