Monday, July 16, 2018

Agile Approach and PMI PMBOK

Decision Requirement:

  • Projects with heavy constraints, inexperienced and dispersed teams, large risks, generally clear up-front requirements, and a fairly rigid completion date are best done using a predictive approach. 
  • In contrast, projects with less rigid constraints, experienced and preferably co-located teams, smaller risks, unclear requirements, and more flexible scheduling would be more compatible with an agile approach.
Scrum includes three main roles for project participants:
  • Product owner: The person responsible for the business value of the project and for deciding what work to do and in what order, as documented in the product backlog.
  • ScrumMaster: The person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers that prevent the team from being effective. ScrumMasters have authority over the process but not the people on the team. They must be comfortable surrendering control to the product owner and team. Some experts suggest that traditional project managers do not make great ScrumMasters. 
  • Scrum team or development team: A cross-functional team of five to nine people who organize themselves and the work to produce the desired results for each sprint. A sprint normally lasts two to four weeks, during which specific work must be completed and made ready for review.
In Scrum, an artifact is a useful object created by people. An artifact can be called a deliverable in other project management approaches. The following three artifacts are created with Scrum:
  • Product backlog: A single list of features prioritized by business value. The highest priority items should be broken down in enough detail for the team to estimate the effort involved in developing them. Some experts suggest scheduling about ten workdays for each item.
  • Sprint backlog: The highest-priority items from the product backlog to be completed within a sprint. The Scrum team breaks down the highest-priority items into smaller tasks that take about 16 hours to complete.
  • Burndown chart: Shows the cumulative work remaining in a sprint on a day-by-day basis.
The ScrumMaster facilitates four ceremonies or meetings when using the Scrum methodology: 
  • Sprint planning session: A meeting with the team to select a set of work from the product backlog to deliver during a sprint. This meeting normally takes four hours to a full day.
  • Daily Scrum: A short meeting for the development team to share progress and challenges and plan work for the day. Ideally the team members are in the same place, the meeting usually lasts no more than 15  minutes, and it is held at the same time and place each day. If that is not possible, teams can use videoconferencing to have short virtual meetings. The ScrumMaster asks what work has been done since yesterday, what work is planned for today, and what impediments or stumbling blocks might hamper the team’s efforts. The ScrumMaster documents these stumbling blocks and works with key stakeholders to resolve them after the daily Scrum. Many teams use the term “issues” for items that do not have to be solved in the next 24 hours and “blockers” for items that need to be immediately addressed. This allows a SrumMaster to maintain focus on highest priority items (blockers) first and then manage the resolution of other issues over the next day or so.
  • Sprint reviews: A meeting in which the team demonstrates to the product owner what it has completed during the sprint.
  • Sprint retrospectives: A meeting in which the team looks for ways to improve the product and the process based on a review of the actual performance of the development team.
Scrum framework in terms of the project management process groups:
  • Initiating:
    • Determine roles
    • Decide how many sprints will compose each release and the scope of software to deliver
  • Planning:
    • Create product backlog
    • Create sprint backlog
    • Create release backlog
    • Plan work each day in the daily Scrum
    • Document stumbling blocks in a list
  • Executing:
    • Complete tasks each day during sprints
    • Produce a shippable product at the end of each sprin
  • Monitoring and Controlling: 
    • Resolve issues and blockers
    • Create and update burndown chart
    • Demonstrate the completed product during the sprint review meeting 
  • Closing:
    • Reflect on how to improve the product and process during the sprint reflection meeting 

Friday, July 13, 2018

Secret Most Successful Project Managers Know

1. Squishing a square into a circle never works

Gantt charts are great for defining a project's scope, budget, and resources, but they aren’t great at adjusting once your project has contact with the real world. This study found that client-based change requests were the primary reason for projects going over time and budget—and traditional Gantt charts don't adjust well for those.
Successful project managers know they need a project tracking platform to help them identify risks as the project progresses—one that gives them real-time feedback with the flexibility to adjust as things come up. With over a third of projects running between one to three months exceeding their scope due to underestimated time frames, you need a dynamic tool that can tell you when something isn't feasiblein time to do something about it
2. Take trends with a grain of salt
Great project managers don’t “copy and paste” ideas from thought leaders and insert them into their own strategy blindly. For instance, while the agile approach works for some, you might realize that on its own it doesn’t bode well for you (i.e. it’s hard to set real deadlines since you’re always trying to figure out how you’d like to accomplish tasks each week). It's important to figure out what parts of a trend or strategy work for you and then, make sure you have a project management platform in place that can adjust on a whim (like you) to get the job done efficiently.

3. Tweak the recipe

What works for some might not work for others—so successful project managers combine methods and create their own unique approach. Then, they build out those strategies on a project management platform that can work exactly the way they want to work(because there’s no one size fits all). Still, many project management solutions force you to run your project within their preset parameters (when it should be the other way around)—so it can be hard to make the tweaks you need to be successful.
Trying to manage and dynamically adjust to the realities of managing a project when the platform you’re using isn't flexible can be frustrating. If this is a pain you’re struggling with right now, then you’ll want to have a look at a platform that’s smart and flexible the way you are.

Other tips:

Tips & tricks for effective project management

1. Write down everything

Project managers are responsible for juggling all of the small details of a project. “It’s easier to sift through notes than to completely forget something".
Makes use of old and new technology by using customized Excel spreadsheets and programs like Asana and 10,000ft. These tools track everything from notes and task management to time and resource planning.

2. Gain your team’s support

All of the technology in the world won’t make you an effective project manager if you don’t have your team behind you. Earn your team’s trust by listening to them, especially about risks and obstacles, recommends Marie Phillips, retired Project Management Institute project management professional. You’ll make more informed decisions if you’ve got a firm handle on your team’s abilities.

3. Communicate well

Communication among your team is essential to success. Tools like Skype and other chat software make it easy to stay in touch with your team at all times. Even with these slick tools, some people may still prefer phone calls or face-to-face interaction.
It is important to understand how each member of your team prefers to communicate. This will help prevent misunderstandings and will allow you to strategize the best way to introduce your team to new technology.

4. Stay enthusiastic with the right tools

The best way to get your team excited about a project is to show that you’re passionate about it yourself. Don’t let your enthusiasm get bogged down by a mess of details. Turn to programs like Harvest to track time and expenses so you can focus on the heart of the project.

5. Get to know keyboard shortcuts

Project managers have a lot on their plates. Cut down on wasted time by learning keyboard shortcuts for your web browser, email and other commonly used programs. This trick will gain you hours of saved time in the long run!

6. Choose the right person for the job

“If you assign the wrong person to a task, you’re reducing your chances of success before the project even begins,” warns Juan Velasquez, marketing and project specialist at Use a site like Trello to track, evaluate and delegate tasks to your team. The simple layout and clear-cut visuals make it the perfect tool for effective task management.

7. Create a readable timeline

The right visuals give you an at-a-glance view of your project’s timeline without requiring you to flip through a calendar. Use Gantt charts to quickly check the progress of a project. Programs likeSmartsheet have Gantt charts already built in, saving you the time and hassle of creating your own.

8. Prepare for tech failure

You need to stay in touch with all of the decision makers on your project, even if your email is down or you spill coffee on your laptop. Be prepared for tech mishaps with a system that keeps your info backed up across multiple devices.
9. Write a postmortem report
Effective project managers are constantly looking for ways to improve. Evaluating each project after the fact will help you recognize what went well and what could have been done differently.
This is the perfect time to evaluate the success levels of the technology and communication tools you used during the project. You can move forward with successful tools as a best practice for future projects.

7 Habits of Highly Successful Mentors & Mentorees

Use these 7 Habits of Highly Successful Mentors and Mentorees to identify the perfect candidates in your organization for your existing mentoring program or to show upper management that you have the right mix of people to launch a program.

1. Active Listeners. Active listening takes energy. People who listen actively don't simply sit back and allow words to hit their eardrums. They sit up straight. They take notes. They ask questions. They repeat or "mirror back" what they've heard to ensure they've understood it properly. Active listeners are the ones who provide non-verbal gestures (e.g. eye contact, nodding, etc.) that indicate they're following (or not following) what you're saying. 

Why is this habit important? Mentors and mentorees spend much of their relationship talking and listening to one another. Active listening is critical for both parties.

2. Dedicated to Their Success. I'm not suggesting that people should have a myopic view and are dedicated to only their own success. What I'm saying is that people who take pride in their work, who want to grow, and who truly care about their career trajectory are assets because of their high expectations. 

3. Dedicated to Others' Success. I put the "success" habits back to back so that it's clear they work in tandem. The most successful (and happiest) people in life are not in it just for themselves. They care about the organization and the people within that organization and have a genuine desire to see everyone and everything succeed: the company, the employees, and the mentoring program as a whole.

Why is this habit important? People who realize that "it's not all about me" are much more willing to make a genuine investment in the mentoring relationship.

4. Curious. People who are naturally curious tend to follow the "if there's a will, there's a way" philosophy. If they don't know the answer or if they need help with something, they won't sit back and wait; they'll go looking for the answers.

5. Engaged with their surroundings. These people view their work as more than just a job. They show interest in the industry, in the world around them, in the work that other departments are doing, and in the charitable events associated with their company. 

Why is this habit important? Having a "big picture" view of the world allows people to see how the success of their mentoring relationship affects more than just the two people in the relationship.

6. Willing to step out of their comfort zones. These people are willing to try new things, consider new thoughts, and think outside of the proverbial box for the sake of personal and professional growth.

Why is this habit important? Prospective mentors and mentorees who are willing to try something new and give it a "go" will have the best chance at reaping the most benefits from the mentoring relationship.

7. The 3 R's: Responsible, Respectful, & Ready. People who are responsible, respectful, and ready to get started with new projects help make the day-to-day work experience a better one not only for themselves, but also for everyone around them. 

Thursday, January 25, 2018

Project Planning - 5 W Questions

With all of the tools, techniques and processes within our profession, we sometimes lose sight of the basic principles of project management.  One way to ensure that you are not over-complicating things is to assess your approach from the perspective of a small child.
On project planning, understanding & communicating the five W’s can provide context and perspective for the low-level details found within the individual project plans.
  1. What – at its very essence, scope definition is about answering the “What do we want to do?” question.  It’s amazing how many projects will consume significant resources (and churn as a result) without having a simple answer.
  2. Why (and Why, Why, Why, and Why?) – if there’s one thing we lose as we grow up, it’s the admirable (?!?) persistence that a small child demonstrates when trying to learn about something new.  We might ask the “Why are we doing this project?” question once or twice, but how often do we probe really deep to understand the fundamental root benefits & motivations that are driving its existence?  We should adopt the traditional performance improvement technique which recommends asking “Why?” five times to ensure that we are not presenting a surface-level driver as the main reason for investing in a project.
  3. Who – Although the What might not have been sufficiently decomposed to identify all of the skills or competencies required, there should be some idea of the critical roles that are required to deliver the What.
  4. When – When is the latest that the What must be delivered to enable the organization to achieve the Why?
  5. Where – where is the optimal location for the work to be performed and where will the What be used?
The project manager’s focus can now shift to the question that too often gets all the attention before there’s a good understanding of the five W’s: How?  This ensures that we don’t spend too much time on approach, methodologies and practices, without having first understood the project’s essence.

Friday, July 7, 2017

BRD- Business Requirements Document

Many businesses have a process in place to assist with project management and implementation. One opportunity for improvement involves making reasonable estimates of how big a project is and how much it is going to cost. There are many different names for tools used with this process: business needs specification, requirements specification or, simply, business requirements. Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.
A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations. If an initiative intends to modify existing (or introduce new) hardware/software, a new BRD should be created. The BRD process can be incorporated within a Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) culture.
The most common objectives of the BRD are:
  • To gain agreement with stakeholders
  • To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
  • To provide input into the next phase for this project
  • To describe what not how the customer/business needs will be met by the solution
The BRD is important because it is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The process function delivers CTQs (critical to quality). CTQs deliver the voice of customer (VOC). The BRD describes what the system would look like from a business perspective.
The BRD distinguishes between the business solution and the technical solution. When examining the business solution the BRD should answer the question, “What does the business want to do?” For example, the business wants to serve 100 bottles of red wine each night during a three-day conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution should support the business solution. For example, the company would need a wine grotto or refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees Fahrenheit.

Who Should Be Involved in the Creation of the BRD?

A number of teams and partners should create the BRD:
  • Project core team
  • Business partner(s)
  • Process owner(s) or representatives
  • Subject matter experts
  • Change/project/product management, quality department and/or IT management as needed or available

Prerequisites for BRD

Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected.
Prerequisite two is a current environment assessment created during the measure phase. This includes a detailed process map of the current environment highlighting areas that will be changed during the project. Detailed “as is” process maps should include:
  • Clearly defined start and end points of the process
  • Level two and three process functions
  • Defined areas of rework and non-value added steps
  • Cycle time, capacity and rework information for each process step as available
  • Baseline for each CTQ for the current environment
Prerequisite three is CTQs, identified in either the define or measure phases, and validated with baseline measurements, targets and specifications.
  • Current measures: Data that defines and describes current performance – sigma level of the CTQ includes a definition of how the product/service’s characteristic is to be quantified.
  • Target/nominal value: What is the aim of the product/service? If there was never any variation in the product/service, this would be the constant value.
  • Specification limits: How much variation is the customer willing to tolerate in the delivery of the product or service? Define upper and lower specification limits as required by the customer needs.
  • Allowable defect rate: How often are the producers willing to produce a product/service outside the specification limits?
Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories:
  • People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)]
  • Systems: Systems is processing information and making decisions
  • Systems/people: System is processing information and people are making the decisions
    • Distinguish between employee and customer
    • Distinguish leadership requirement for associate in case decision making authority has to be moved up
  • Fishbone: For each process function for impact assessment

Overall Project Details and Best Practices

The BRD appendix can be used to list a number of project details – constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project. Consider the following issues when looking at the overall project:
  • Are there any regulatory or geographic constraints (i.e., state law) to consider? If so, these constraints need to be clearly documented in the process detail table of the BRD or in the overall project details section of the appendix.
  • What assumptions or dependencies apply?
  • What business rules apply?
  • Are there any measurements or reporting requirements that apply to the project?

Best Practices

  1. Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process.
  2. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for:
    • People
    • Process
    • Technology
    • Materials and supplies
    • Facilities
    • Product
    • Machinery and equipment
    • Others as necessary (depending on the organization)
  3. Definitions and acronyms: Define any terms not clearly understood by all.

Packaging the BRD

Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of sections follows:
  • Project overview including project charter information, scope, and objectives
  • Current environment assessment and systems overview (see additional details below)
  • Future process map
  • Process detail table
  • Overall project business rules and constraints
  • Impact assessment (fishbone for process functions)
  • Functional requirements (additional details below)
  • Data to be held (additional detail available below)
  • Schedule and budget
  • Terms and definitions
  • Approver information
  • Team information

Business Partner Sign-off

Business partners should be active participants in the development of the BRD, but a final review and sign-off is also essential.

Additional Details

There are a number of items included in the BRD that require detailed documentation to ensure successful implementation. Following is a high-level overview of the types of detail to consider:
Sample questions for the current environment assessment and systems overview:
  • Who is the intended user?
  • How many users are there? Are they the same type of user or different?
  • What level of computer experience will the users have (or is needed)?
  • What is the required security?
  • Are there hardware constraints – networked or stand-alone?
  • What are the approximate numbers of records required initially plus the anticipated growth?
  • What technical support is necessary and available in-house?
  • What other systems need to integrate/communicate?
  • Backup. Describe the current back-up regime (e.g., tape back-up one/day). How will the new system fit with this? If this is not currently defined then think how much data could be inadvertently lost. For example would it be a major disaster if the last 30 minutes of work was lost, or could yesterday’s/last week’s data be retained?
  • Deliverables. What are the expectations – system, help files, documentation, full source code, training, support, etc.? Detail what is essential versus nice. Do not automatically ask for everything unless necessary. If the project manager is to maintain the system make sure he states that he requires the full source code – alternatively if the developer is to maintain the system consider settling for an escrow agreement (where the source is held by an independent third party). Be specific about tools necessary to help. If the developer is unwilling to provide the support necessary find someone else who will.
The functional requirements section should describe “what” the system is to accomplish rather than the “how.” Develop a prioritized list similar to the following:
  • A detailed description of the requirement including goals (e.g., produce a report of spend/department/year on demand with the user selecting the department and the financial year required), it is necessary to know how the company defines the financial year.
  • How important is this requirement (essential, preferred, nice to have, not essential, etc.)?
  • Any known design/implementation issues relating to this requirement?
  • Does this requirement interact with other requirements?

Data to be Held: Sample Advice

Describe expected data tables. Examples include customer records, contact details, machine records, etc. Provide as much detail as possible – a customer record might consist of a name, address, telephone number, fax, mobile number, region, business type, number of employees etc. Indicate any unique fields (such as a job number) and show how different tables relate to each other (very important). For example projects are related to customers through a customer number. Each customer can have none, one or many associated projects. Each project relates to one or more jobs. A job can exist independently of a project but will still be associated with a customer. A project will always have only one customer.
It is not usually necessary to define the tables in database terms (e.g., customer number is a long integer) but examples of the data to be held in the fields is useful (e.g., a typical job number might be FH/1234 where FH indicates the department undertaking the job and 1234 is a unique number. In practice a good database designer would then recognize that the “real” job number is actually the 1234 part and the FH is just an associated field). If the maximum size of any field is known – for example, a “Company Name” field is 100 characters – then include this. If there are any table definitions from existing systems then provide these indicating any required changes.


As with any tool, the BRD can have both benefits and failure modes. Benefits derived from a good BRD include reduced changes during the improve and control phases of DMAIC and reduced time to deployment. Failure modes from a poor BRD means the system developed will not meet business requirements. Creating a successful BRD requires planning and coordination. There are a few best practices that should be followed in this process. The team should hold a dedicated off-site session to complete the BRD with all required resources 100 percent available. Scheduling is the key to success here. As each tool/deliverable is completed within the methodology build the BRD. Allow a one-week deadline to finish action items from the off-site session and hold a final review session two to three hours after completion of action items.

Thursday, August 25, 2016

Common Business Analyst Deliverables

Common Business Analyst Deliverables

 Project Stage
 Document Name
 Brief Description
 Project initiation
 Vision document
Business case
Feasibility study
 The purpose is to:
·       Set out and gain consensus of the direction of the project and scope from the senior stakeholders.
·       Justifies the benefits and estimated costs.
·       It will provide enough evidence that the money is worth being spent, allow funding to be agreed or will show that it isn’t worth doing which then prevents further money being wasted.
·       It makes sure that the overall solution is agreed and that it will meet the business needs.
Business process mapping document
 It contains “as is” and “to be” business process diagrams.  The purpose of it is to:
·       Understand the business processes.
·       Help identify the problems and opportunities for change.
·       Understand the scope of the requirements as each requirement should relate to a process.  This is why it should always be done before the business requirements document.
·       Business stakeholders are more likely to be know their business processes better than their requirements.   Therefore this is a better starting point and further justification for doing this first.
 Business requirements document
 It contains a catalogue for all of the business requirements, a priority for each and a justification.
The purpose of it is to:
·       Gain a consensus and understanding of all of the business requirements in scope for the project
·       Understand which of the requirements are mandatory to the extent that if they weren’t delivered the project would not be worth doing.
·       Pre-requisite for being able to start system requirements to ensure trace-ability.
 Use case model
Context diagram
 It contains a use case model which is a UML (Unified modelling language) tool or a context diagram.
The purpose of it is to:
·       Identify system boundaries (which systems are in scope).
·       Identify the use cases (goals) for each of the systems in scope.  This is a summary of all of the things the system has to do.
·       Identify the human and system interfaces for each of the goals.
·       Allow estimation and planning depending upon the number of use cases and the complexity and size.
·       Pre-requisite for the system requirements.
 System requirements document
Functional requirements document
Use cases
User stories
User story boards
 It contains all of the requirements that need to be met by the project systems in scope.
The purpose of it is to:
·       Ensure the system requirements will meet each of the relevant business requirements and is understood and acceptable to the business stakeholders.
·       Ensure the system requirements are understood and acceptable to the IT stakeholders.
·       Allows developers to code the systems in scope according to the system requirements.
Non-functional requirements document
 It is really important that non-functional requirements are gathered early on and aren’t missed out.
The purpose of it is to:
·       Set out non-functional requirements.  A non-functional requirement is a quality, constraint or behaviour that the system being built must meet.
·       To ensure the system being developed is adequate as involves a wider variety of IT stakeholders than the developers and a wider set of questions to the business stakeholders.  For example will the system have adequate enough capacity for the volumes of data anticipated.
 Data mapping document
 This document focuses on data requirements.
The purpose of it is to:
·       Identify all of the types of data required and agree a consensus of the names to be used and definitions.
·       Identify all of the relationships between each type of data and the data down to field/attribute level.
·       Provide a logical data model which can be used to work out a physical data model.
·       Ensure all of the data required can be met.
 RFP stands for Request for proposal. It is written when goods or services are required from an outside supplier where no products or expertise are currently available to meet the needs of the project within the company.
The purpose of it is to:
·       specify the needs and allows other companies to bid for the work.
 Evaluation scoring matrix
 This is written in conjunction with the RFP.  The purpose of it is to:
·       Agree the success criteria to ensure the best vendor is selected.
·       Allow all scorers to follow the same success criteria.
·       Provide objectivity to the process
 Options paper
 If problems are encountered the business analyst can write an options paper.  The paper should be short and:
·       Specify the problems encountered and the reasons.
·       What the potential options are to resolve the problem.
·       Make a recommendation with reasons
The purpose of it is to:
·       Allow problems and resolutions to be understood and agreed so the project can proceed.
 Design / testing / implementation
 Gap analysis document
 This may be carried out at several stages to ensure that what is being produced traces back to:
·       The requirements.
·       The scope.
·       The benefits expected.
 Testing / implementation
 Test strategy / test scripts
 Normally tester deliverables, however there may be occasions where the business analyst may contribute to writing the, be a reviewer, carry out testing or help co-ordinate with other testers and business users.
The purpose of it is to:
·       Ensure all of the different business scenarios will be met by the system being changed.
 Testing / implementation
 Training materials / new business processes
 Normally a trainer deliverable.  However there may be occasions where the business analyst may document new business processes and ensure training manuals are kept up to date.
 Testing / implementation
 Handover documentation
 If the business analyst encounters several problems during the delivery process they may be best placed to put a handover document together for various parties to ensure resolutions have been formally captured.  This is particularly important if any new manual workarounds get introduced as a result.