All I KNOW 'N' PRACTICE - TECH SOMMELIER

11 technologies of next decade

2017-12-08T06:15:00.003-08:00

11 technologies of next decade:

1 #AI (machine/deep learning, NLP)
2 #IoT⌚️
3 smart robotics 🤖
4 3D print 🖨
5 mobile📱
6 autonomous cars 🚙
7 mobile internet 💻
8 #blockchain ⛓
9 mixed reality VR/AR 👓
10 wireless power 🔌
11 quantum computing 💡

Why 90% of startups fails ?

2017-12-08T05:35:00.000-08:00

Why 90%of startups fail:

1 no market need
2 no cash
3 wrong team
4 competition
5 price
6 poor product
7 lacklustre business model
8 poor marketing
9 ignore customers
10 mis-timed
11 lose focus
12 disharmony
13 pivot gone bad
14 lack passion
15 bad location
16 no financing/ investor interest
17 legal challenges
18 no advisors
19 burn out
20 fail to pivot

How to reduce your project stress

2017-12-08T05:27:00.003-08:00

How to reduce your project stress:

1 don't respond to negativity
2 go for a walk, be active
3 be honest to your timeline
4 read, write more
5 give without expecting a get
6 breathe deeply
7 forgive first
8 write thank you notes
9 be a better friend
10 you are not your job
11 complain less
12 laugh more

Enterprise Collaboration - Industry Trends and Best Practices

2017-07-20T02:00:00.002-07:00

Enterprise collaboration is at the heart of radical transformation and necessity in modern business. It creates value by modifying social tendencies and communications that are prevalent in the non-work environment and applying them to the professional sphere. Doing so captures the benefits of increased efficiency, cost savings, and more effective distribution tasks among employees. Web and mobile-based collaboration tools and methods seek to capture human social interaction within a technology-based solution to business needs. Perhaps one of the most well known examples of this is the International Space Station (ISS), which is a result of 15 nations working together. People have lived in space every single day since the year 2000. The space station has become a home in orbit from where people do research, which cannot be done on Earth.

No matter if you’re a large enterprise or a small startup, live in Shanghai or San Francisco, work from home or the ISS, we all face the same challenges. We need effective collaboration to achieve magic together.

In a raging disruptive world, it is difficult to distinguish signal from noise. That’s the exact reason why we IT team sat down to think about what trends we believe might shape the year ahead at the organisation. We wanted to use these insights internally for ourselves, as well as share it with all at organisation!

Current Trends in Industry

1. Collaboration tools move beyond social

The last many years we have seen a disruption of social collaboration tools. Apps such as Yammer have done a tremendous job in connecting people. But while connecting people was an obvious first step to go, all our work processes remain highly siloed and disconnected.

Many of the apps we use today are limited by structure and technology. They have been developed to work individually and in silos. The result is broken work processes and a productivity potential waiting to be realized. A software development team might be using one system for tracking bugs, another to invoice clients and a third to track time.

Trying to stitch legacy apps together has previously been time-consuming and required lots of development hacks. But open API’s and a standardized cloud are making integrations of different software apps much more easier than before.

The next step will be to connect broken work processes and apps.

Instead of having work processes existing in closed apps, we’ll see new platforms emerge, converge and work together in unimaginable ways. The collaboration market will effectively become an ecosystem in its own right. Poject management apps will integrate to task management apps. Task management apps will integrate to invoicing apps. Invoicing apps will integrate to time tracking apps etc. Connecting work holds a promise of higher productivity waiting to be unleashed

2. BYOS - Bring your own collaboration tools to the office

The boundaries between work and home are blurring, so collaboration software must allow people to work seamlessly across platforms, devices and locations. Many of our peer companies now allow users to bring their own device to the office (BYOD). If you walk into any modern enterprise, it’s not uncommon to see all kinds of phones being used and governed by IT and users – something previously not allowed.

In a similar way, we foresee that 2017 will be the year when Bring Your Own Software (BYOS) to the corporate workplace will kick off. People are already using a variety of software to collaborate. From Dropbox to Box, Google Hangout to Skype, Wrike to Asana, Slack to Skarpline, Trello to Pivotal Tracker and the list could go on.

Most of these products offer simple transparent pricing plans, which are easy to administer and govern. Instead of having IT dictating what to use, why not let users become strong ambassadors, manage their own software and decide what’s fit for their role?

Using software to access BYOS has several benefits to the user and company. The user will often have access to a wide range of services. Is Lync down? Use Skype or Team Viewer. And companies enjoy solutions that come with freemium packages in most cases.

3. The collaborative organisation

Many organisations have invested heavily in technology over the past decades. These investments are often pursued top-down and measured on ROI. But how do you measure ROI when implementing a collaboration tool?

The next step for technology organisations is to become collaborative organisations. Collaborative organisations implement tools buttom-up. Instead of looking at ROI, they look at usage. Are our employees actually using these tools? Do they provide a better fit for the individual employee and his or her work process? Do these tools ‘almost’ implement themselves using smart onboarding and intuitive interfaces?

Research shows that productivity growth only happens when technology is accompanied by concurrent changes in how we work. In fact, technology adoption alone, without the accompanying changes in work practices, have little or even a negative impact on productivity.

Don’t pursue collaboration tools for the sake of cool technologies. Pursue it with an intention to improve how you work. Most solutions offer freemium or trial version to get you started. Measure the usage. If people are using it, you’ll see an increase in performance, productivity and happiness at work.

4. Bots everywhere

Bots are ‘conversational software robots’, which have exploded in usage the recent months. They are mostly found in messaging and chat applications, but given their collaborative nature, we expect to see them across a variety of collaboration tools in the near future.

Bots help us automate conversations and tasks. They can help us get started with an app, reserve dinner appointments, schedule meetings or pay online. Without interacting with another person. Instead of you typing a command, a bot is typing commands for you. All you do is having a conversation with what seems like a real person, but in fact it is a ‘bot’.

2017 will bring us a variety of new use cases centered around bots, and some will come to feel like artificial intelligence. We’re already now seeing several open platforms offering platforms for other platforms. It truly is an open world of collaborative platforms!

5. VR and Visual Collaboration

We’ll increasingly see new collaboration tools experiment with new user interfaces to simplify and make collaboration more intuitive.

The next wave of usage onto less technical people will bring a new wave of user experiences to the market. Many collaboration tools have been embraced by technical communities. But just as Windows took over MS-DOS and became an intuitive operating system for a larger audience, we’ll see collaboration solutions do the same.

Imagine using virtual reality headset to collaborate. Or gigantic touch screens in every office room from where you can manage your project with a single touch. Several products are already highly visual and capable of this transformation. From project management solutions such as Trello and Asana, roadmap and process solutions as Aha! and ProductPlan, recognition tools as DaPulse to communication tools as Skarpline.

Improved visualization and usability will lead to companies not only purchasing online collaboration software but an increased number of employees actually using the software and hence achieving the benefit of a higher productivity.

Best Practices and Way Forward

1. Tightly integrate people for resultant productivity

Introducing SharePoint online, Microsoft Teams, Yammer and Lync at workplace gets you rich picture of the people behind the work and rich productivity dividend. The way work gets done is by people working with people, “bouncing ideas” off each other, tapping into each other’s expertise, leveraging each other’s knowledge and insights, repurposing each other’s output. Yammer gives a rich picture of the people behind the work and Microsoft Teams enables you to gauge self-productivity at work place. It connect people and give them a full picture of each other. When people have the context of the who, what, when, where and why of the others they are working with, it builds the level of trust they have in each other and results in greater teamwork and higher quality work.

SharePoint Online: Sharepoint Online of Office 365 helps you to access intranet anywhere, anytime with seamless collaboration, enables intelligent insight along with enterprise grade security compliance

Microsoft Teams: A hub of team work. The chat-based workspace in Office 365 brings together all the people, conversations, files, and tools your team needs to be more effective

Yammer: Connect people across your organization and keep teams engaged. Helps in Crowdsource ideas, tap into collective knowledge, and get the pulse of your company. The group feed fosters open discussion and encourages team members to collaborate and share best practices. Actionable updates and alerts keep everyone up to date and involved in the process.

2. Make sure it fits the way people work

Email Integration: Putting Outlook and Active Directory together on Office 365 gives a great opportunity to reduce your investment and maintenance cost heavily. Since employees rely heavily on email, email integration is critical. Office 365 solution allow users to easily create a tasks from email for team member, share information on personalised mysite

Mobile Support: Today’s workers rely heavily mobile devices. People are accustomed to being able to get work done on the go. For a collaboration solution to get high adoption, it needs to work seamlessly with mobile devices so people can continue to collaborate on the go. Office 365 gives immense one stop solution for such road warriors.

Office 365 outlook, AD and Lync: All these tools together can create a workplace magic for any organisation. Keeping all of them on Office 365 cloud, gives a clear organisational edge for collaboration, accessibility and high user experience with very less cost of ownership, zero/low maintenance activity, heavy reduction in overheads on managing on-premises assets, resources and heavy datacenters.

Top 5 Key Reasons Why Projects Fails

2016-02-15T02:56:00.001-08:00

If you’re frustrated that one of your projects just can’t seem to get off the ground, it might be because these practices aren't being followed.

1. Set a timeline

Every project you start must have an end date. Be realistic about how much time a project will take to accomplish. If you budget too little time, you may end up feeling defeated. If you consistently budget too much your time for projects, well, you’ll get a lot less done than you’re capable of.

If you are unsure what steps should be taken to achieve your goal and so can't create a realistic timeline, start by asking questions. Only when you have a firm grasp about what needs to be done, can you start setting effective project deadlines.

2. Collaborate with Team: Get everyone on the same page

You can’t do some projects on your own. So assemble a team before starting the project and let every member of the group know what you’ll need from them. If people don’t understand what's expected of them, they won’t be able to deliver.

Go a step further and be sure that members of the team understand the big picture. What's the goal of the project? How will you achieve it? Why is each person’s contribution important?

Even before sitting down with the team for a meeting, send an agenda in advance. Never end a meeting with the team without cementing the steps that must be taken next and who's responsible for them.

3. Status Review: Weekly stakeholders meetings

Setting a timeline and clarifying who is responsible for what isn’t enough. You must keep people accountable by regularly checking in with them. I use a project tracker to keep abreast of what everyone is up to. It functions like a scorecard: Everyone is aware of what’s getting done and who’s doing it.

It’s obvious when someone is falling behind. This makes it easy for someone else to step in and volunteer to help out. At our weekly meetings, we review the project tracker and talk about what’s working and what isn’t. Keep your meetings short and don’t veer from the agenda.

4. Stakeholder Availability: Key players should make themselves available

If you want to make sure a project gets done, force everyone who's taking part to be accessible. Do your part by leading through example. Respond to emails and phone calls promptly. When you have so much going on, it’s easy for something to slip through the cracks. The easiest way to avoid that is to be accessible and respond promptly,

5. Promote transparency

Whether the news is good or bad, members of your team will work harder when they feel they're in the know. Do all that you can to encourage the people you work with to take ownership of the project.

Staying on top of many projects isn’t easy, but it's possible.

PMP Tools and Technique

2012-07-11T07:28:00.001-07:00

4.1 Develop Project Charter — PG – Initiating — KA- Integration Management
Input	Tools & Techniques	Output
Project statement of work	Expert judgment	Project charter
Business case
Contract (if third party project)
Enterprise Enviornmental Factors (EEF): government/industry standards, organizational infrastructure, marketplace conditions
Organisational Process Assets (OPA): Org’s standard processes, policies, definitions, templates, historical info and lessons learned
4.2 Develop Project Management Plan — PG – Planning — KA- Integration Management
Input	Tools & Techniques	Output
Project charter	Expert judgment	Project management plan
Outputs from Planning process
EEF: Government/industry standards, org structure/infrastructure/culture, project management system
OPA: Standardized guidelines, proposal/performance eval criteria, PMP templates, closure templates, change control procedures, previous project docs like calendars, registers, and baselines.
4.3 Direct And Manage Project Execution — PG – Executing — KA- Integration Management
Input	Tools & Techniques	Output
Project management plan	Expert judgment	Deliverables
Approved change requests	Project management information system	Work performance information
EEF: Infrastructure, personnel rules, stakeholder risk tolerances, project management information systems		Change requests
OPA: Standardized work guidelines, communication requirements, defect management procedures, project files from previous projects		Project management plan updates
		Project document updates
4.4 Monitor and Control Project Work — PG – Monitoring & Controlling — KA- Integration Management
Input	Tools & Techniques	Output
Project management plan	Expert judgment	Change requests
Performance reports		Project management plan updates
EEF: Industry/Gov standards, stakeholder risk tolerances, project management information systems		Project document updates
OPA: org communications requirements, financial controls procedures, defect management procedures, risk control/categories/matrices
4.5 Perform Integrated Change Control — PG – Monitoring & Controlling — KA- Integration Management
Input	Tools & Techniques	Output
Project management plan	Expert judgment	Change request status updates (approved change requests and denied change requests)
Work performance information	Change control meetings	Project management plan updates
Change requests		Project document updates
EEF: project management information system such as a scheduling tool
OPA: change control procedures, process measurement database, project files like baselines, configuration management databases
4.6 Close Project or Phase — PG – Closing — KA- Integration Management
Input	Tools & Techniques	Output
Project management plan	Expert judgment	Final product, service, or result transition
Accepted deliverables		OPA updates
OPA: closure guidelines, audits, evaluations and other project docs
5.1 Collect Requirements — PG Planning — KA Scope Management
Input	Tools & Techniques	Output
Project charter	Interviews	Requirements documentation
Stakeholder register	Focus groups	Requirements management plan
	Facilitated workshops	Requirements traceability matrix
	Group creativity techniques: brainstorming, nominal group technique, Delphi technique, idea/mind mapping, affinity diagram.
	Group decision making techniques: unanimity, majority, plurality, dictatorship
	Questionnaires and surveys
	Observations
	Prototypes

5.2 Define Scope — PG Planning — KA Scope Management
Input	Tools & Techniques	Output
Project charter	Expert judgment	Project scope statement
Requirements documentation	Product analysis	Project document updates
OPA: Scope statement policies, procedures and templates. Previous project files and lessons learned.	Alternatives identification
	Facilitated workshops
5.3 Create WBS — PG – Planning — KA – Scope Management
Input	Tools & Techniques	Output
Project scope statement	Decomposition	WBS
Requirements documentation		WBS dictionary
OPA: WBS policies, procedures, and templates. Previous project files, lessons learned		Scope baseline
		Project document updates
5.4 Verify Scope — PG – Monitoring & Controlling — KA – Scope Management
Input	Tools & Techniques	Output
Project management plan	Inspection	Accepted deliverables
Requirements documentation		Change requests
Requirements traceability matrix		Project document updates
Validated deliverables
5.5 Control Scope — PG – Monitoring & Controlling — KA – Scope Management
Input	Tools & Techniques	Output
Project management plan	Variance analysis	Work performance measurements
Work performance information		OPA updates
Requirements documentation		Change requests
Requirements traceability matrix		Project management plan updates
OPA: scope related policies, guidelines, procedures. Monitoring and reporting methods to be used.		Project document updates
6.1 Define Activities — PG – Planning — KA – Time Management
Input	Tools & Techniques	Output
Scope baseline (WBS, WBS dictionary, and Project Scope Statement)	Decomposition	Activity list
EEF: PMIS (project management information system)	Rolling wave planning	Activity attributes
OPA: activity planning related policies, procedures, guidelines. e.g. the scheduling methodology.	Templates	Milestone list
	Expert judgment
6.2 Sequence Activities — PG – Planning — KA – Time Management
Input	Tools & Techniques	Output
Activity list	Dependency determination	Project schedule network diagrams
Activity attributes	Precedence diagramming method (PDM)	Project document updates
Milestone list	Applying leads and lags
Project scope statement	Schedule network templates
OPA: e.g. scheduling methodology files, previous project network diagrams
6.3 Estimate Activity Resources — PG – Planning — KA – Time Management
Input	Tools & Techniques	Output
Activity list	Expert judgment	Activity resource requirements
Activity attributes	Alternatives analysis	Resource breakdown structure
Resource calendars	Published estimating data	Project document updates
EEF: e.g. resource availability and skills	Bottom-up estimating
OPA: Policies and procedures for staffing, renting and purchasing, historical resource usage information	Project management software
6.4 Estimate Activity Durations — PG – Planning — KA – Time Management
Input	Tools & Techniques	Output
Activity list	Expert judgment	Activity duration estimates
Activity attributes	Analogous estimating (top down)	Project document updates
Activity resource requirements	Parametric estimating (plotted forecasts)
Resource calendars	Three-point estimating (PERT)
Project scope statement	Reserve analysis
EEF: Reference data, e.g. duration estimating databases, productivity metrics, published commercial information
OPA: historical duration information, project calendars, scheduling methodology and lessons learned.
6.5 Develop Schedule — PG – Planning — KA – Time Management
Input	Tools & Techniques	Output
Activity list	Schedule network analysis	Project schedule
Activity attributes	Critical path method	Schedule baseline
Project schedule network diagram	Critical chain method	Schedule data
Activity resource requirements	Resource leveling	Project document updates
Activity duration estimates	What-if scenario analysis
Resource calendars	Applying leads and lags
Project scope statement	Schedule compression
EEF: e.g., a company’s scheduling tool	Scheduling tool
OPA: Scheduling methodology and project calendar
6.6 Control Schedule — PG – Monitoring & Controlling — KA – Time Management
Input	Tools & Techniques	Output
Project management plan	Performance reviews	Work performance measurements
Project schedule	Variance analysis	OPA updates
Work performance information	Project management software	Change requests
OPA: Schedule control tools, related policies, guidelines, procedures. Monitoring and reporting methods to be used.	Resource leveling	Project management plan updates
	What-if scenario analysis	Project document updates
	Adjusting leads and lags
	Schedule compression
	Scheduling tool
7.1 Estimate Costs — PG – Planning — KA – Cost Management
Input	Tools & Techniques	Output
Scope baseline	Expert judgment	Activity cost estimates
Project schedule	Analogous estimating	Basis of estimates
Human resource plan	Parametric estimating	Project document updates
Risk register	Bottom-up estimating
EEF: Market conditions, published commercial information	Three-point estimates
OPA: cost estimating policies and templates, historical information and lessons learned	Reserve analysis
	Cost of quality
	Project management estimating software
	Vendor bid analysis
7.2 Determine Budget — PG – Planning — KA – Cost Management
Input	Tools & Techniques	Output
Activity cost estimates	Cost aggregation	Cost performance baseline
Basis of estimates	Reserve analysis	Project funding requirements
Scope baseline	Expert judgment	Project document updates
Project schedule	Historical relationships
Resource calendars	Funding limit reconciliation
Contracts
OPA: cost budgeting related policies, procedures, and guidelines. Cost budgeting tools, reporting methods
7.3 Control Costs — PG – Monitoring & Controlling — KA – Cost Management
Input	Tools & Techniques	Output
Project management plan	Earned value management	Work performance measurements
Project funding requirements	Forecasting	Budget forecasts
Work performance information	To-Complete Performance Index (TCPI)	Organization process assets updates
OPA: cost control-related policies procedures and guidelines. Cost control tools and monitoring / reporting methods to be used.	Performance reviews	Change requests
	Variance analysis	Project management plan updates
	Project management software	Project document updates
8.1 Plan Quality — PG – Planning — KA – Quality Management
Input	Tools & Techniques	Output
Scope baseline	Cost-benefit analysis	Quality management plan
Stakeholder register	Cost of quality	Quality metrics
Cost performance baseline	Control charts	Quality checklists
Schedule baseline	Benchmarking	Process improvement plan
Risk register	Design of experiments	Project document updates
EEF: Associated rules, standards, and guidelines. Government agency regulations. Product’s working / operating conditions.	Statistical sampling
OPA: Organizational quality policies, procedures, and guidelines, historical databases, lessons learned, quality policy (either an endorsed as-is policy or one created by the PM and communicated to stakeholders.)	Flowcharting
	Proprietary quality management methodologies (e.g. Six Sigma)
	Additional quality planning tools (Group decision techniques, matrices, ..)
8.2 Perform Quality Assurance — PG – Executing — KA – Quality Management
Input	Tools & Techniques	Output
Project management plan	Plan Quality and Perform Quality Control tools and techniques	OPA updates
Quality metrics	Quality audits	Change requests
Work performance information	Process analysis	Project management plan updates
Quality control measurements		Project document updates
8.3 Perform Quality Control — PG – Monitoring & Controlling — KA – Quality Management
Input	Tools & Techniques	Output
Project management plan	Cause and effect diagrams	Quality control measurements
Quality metrics	Control charts	Validated changes
Quality checklists	Flowcharting	Validated deliverables
Work performance measurements	Histogram	OPA updates
Approved change requests	Pareto chart	Change requests
Deliverables	Run chart	Project management plan updates
OPA: quality standards and policies, standard work guidelines, and issue / defect reporting procedures	Scatter diagram	Project document updates
	Statistical sampling
	Inspection
	Approved change requests review
9.1 Develop Human Resources Plan — PG – Planning — KA – Human Resource Management
Input	Tools & Techniques	Output
Activity resource requirements	Organisation charts and position descriptions	Human Resources plan: roles and responsibilities, org charts and staffing management plan: resource calendars, acquisition and release, recognition and rewards, safety, compliance and training.
EEF: Company culture, organization, HR, personnel policies, market	Networking
OPA: org chart templates, historical project org info, standard processes and roles descriptions	Organizational theory
9.2 Acquire Project Team — PG – Executing — KA – Human Resource Management
Input	Tools & Techniques	Output
Project management plan	Pre-assignment	Project staff assignments
EEF: Org’s skill levels and structure, personnel policies, locale,	Negotiation	Resource calendars
OPA: Org’s standard policies, processes, and procedures	Acquisition	Project management plan updates
	Virtual teams
9.3 Develop Project Team — PG – Executing — KA – Human Resource Management
Input	Tools & Techniques	Output
Project staff assignments	Interpersonal skills	Team performance assessments
Project management plan	Training	EEF updates
Resource calendars	Team-building activities
	Ground rules
	Co-location
	Recognition and rewards
9.4 Manage Project Team — PG – Executing — KA – Human Resource Management
Input	Tools & Techniques	Output
Project staff assignments	Observations and conversation	EEF updates
Project management plan	Project performance appraisals	OPA updates
Team performance assessments	Conflict management	Change requests
Performance reports	Issue log	Project management plan updates
OPA: bonus structures, certificates of appreciation, newsletters, perks	Interpersonal skills
10.1 Identify Stakeholders — PG – Initiating — KA – Communication Management
Input	Tools & Techniques	Output
Project Charter	Stakeholder analysis	Stakeholder register
Procurement Documents	Expert judgment	Stakeholder management strategy
EEF: Company Culture, structure, government and industry standards
OPA: Stakeholder register templates, previous stakeholder registers, lessons learned
10.2 Plan Communications — PG – Planning — KA – Communication Management
Input	Tools & Techniques	Output
Stakeholder register	Communication requirements analysis	Communications management plan
Stakeholder management strategy	Communication technology	Project document updates
EEF: All the other EEF are used here	Communication models: components are encoding, message/feedback, medium, noise, and decoding
OPA: Lessons learned and historical info from previous projects, as well as all other OPAs.	Communication methods: push, pull and interactive
10.3 Distribute Information — PG – Executing — KA – Communication Management
Input	Tools & Techniques	Output
Project management plan	Communication methods: mostly push method, like email, memos, etc, but include meetings, teleconferences, online chat, etc.	OPA updates
Performance reports	Information distribution tools
OPA: information distribution guidelines and policies, lessons learned and historical project information
10.4 Manage Stakeholder Expectations — PG – Executing — KA – Communication Management
Input	Tools & Techniques	Output
Stakeholder register	Communication methods	OPA updates
Stakeholder management strategy	Interpersonal skills	Change requests
Project management plan	Management skills	Project management plan updates
Issue log		Project document updates
Change log
OPA: org communication requirements, change control and issue management procedures
10.5 Report Performance — PG – Monitoring & Controlling — KA – Communication Management
Input	Tools & Techniques	Output
Project management plan	Variance analysis	Performance reports
Work performance information	Forecasting methods	OPA updates
Work performance measurements	Communication methods	Change requests
Budget forecasts	Reporting systems
OPA: report templates, measurement indicator definitions, organization’s variance limits
11.1 Plan Risk Management — PG – Planning — KA – Risk Management
Input	Tools & Techniques	Output
Project scope statement	Planning meetings and analysis	Risk management plan
Cost management plan
Schedule management plan
Communications management plan
EEF: risk attitudes and tolerances
OPA: stakeholder registers, risk categories, common definitions, templates
11.2 Identify Risks — PG – Planning — KA – Risk Management
Input	Tools & Techniques	Output
Risk management plan	Documentation reviews	Risk register
Activity cost estimates	Information gathering techniques
Activity duration estimates	Checklist analysis
Scope baseline	Assumptions analysis
Stakeholder register	Diagramming techniques
Cost management plan	SWOT analysis
Schedule management plan	Expert judgment
Quality management plan
Project documents
EEF: Risk attitudes, benchmarking, and published information: checklists, databases, studies.
OPA: Project files, process controls, risk statement templates, lessons learned.
11.3 Perform Qualitative Risk Analysis — PG – Planning — KA – Risk Management
Input	Tools & Techniques	Output
Risk register	Risk probability and impact assessment	Risk resister updates:
		Risk category grouping
		Project risk ranking
		Watchlist
		Probability estimates of project objectives
		Trends of the above data during the project
Risk management plan	Probability and impact matrix
Project scope statement	Risk data quality assessment
OPA: similar project info and project studies, industry risk databases	Risk categorization
	Risk urgency assessment
	Expert Judgment
11.4 Perform Quantitative Risk Analysis — PG – Planning — KA – Risk Management
Input	Tools & Techniques	Output
Risk register	Data gathering and representation techniques: interviewing, probability distributions	Risk resister updates:
		List of prioritized, quantified risks
		Contingency time and cost reserves
		Project estimates: Time and Date vs. Confidence
		Probability estimates of project objectives
		Trends of the above data during the project
Risk management plan	Quantitative risk analysis and modeling techniques: sensitivity analysis, EMV analysis/decision tree, modeling and simulation (e.g. monte carlo)
Cost management plan	Expert judgment
Schedule management plan
OPA: similar project info and project studies, industry risk databases
11.5 Plan Risk Responses — PG – Planning — KA – Risk Management
Input	Tools & Techniques	Output
Risk register	Strategies for negative risks or threats	Risk resister updates:
		Residual risks
		Secondary risks
		Contingency plans
		Risk response owners
		Fallback plans
		Risk triggers
		Contracts
		Reserves
Risk management plan	Strategies for positive risks or opportunities	Risk-related contract decisions
	Contingent response strategies	Project management plan updates
	Expert judgment	Project document updates
11.6 Monitor And Control Risks — PG – Monitoring & Controlling — KA – Risk Management
Input	Tools & Techniques	Output
Risk register	Risk reassessment	Risk register updates
Project management plan	Risk audits	OPA updates: technical documentation and assumptions
Work performance information	Variance and trend analysis	Change requests
Performance reports	Technical performance measurement	Project management plan updates
	Reserve analysis	Project document updates
	Status meetings
12.1 Plan Procurements — PG – Planning — KA – Procurement Management
Input	Tools & Techniques	Output
Scope baseline	Make-or-buy analysis	Procurement management plan
Requirements documentation	Expert judgment	Procurement statements of work
Teaming aggreements	Contract types	Make-or-buy decisions
Risk register		Procurement documents
Risk-related contract decisions		Source selection criteria
Activity resource requirements		Change requests
Project schedule
Activity cost estimates
Cost performance baseline
EEF: market, availability, suppliers, locale, industry T&Cs
OPA: purchasing policies, management systems, supplier system
12.2 Conduct Procurements — PG – Executing — KA – Procurement Management
Input	Tools & Techniques	Output
Project management plan	Bidder conferences	Selected sellers
Procurement documents	Proposal evaluation techniques	Procurement contract awards
Source selection criteria	Independent estimates	Resource calendars
Qualified seller list	Expert judgment	Change requests
Seller proposals	Advertising	Project management plan updates
Project documents	Internet search	Project document updates
Make-or-buy decisions	Procurement negotiations
Teaming aggreements
OPA: prospective/qualified seller lists, historical seller information
12.3 Administer Procurements — PG – Monitoring & Controlling — KA – Procurement Management
Input	Tools & Techniques	Output
Procurement documents	Contract change control system	Procurement documentation
Project management plan	Procurement performance reviews	OPA updates
Contract	Inspections and audits	Change requests
Performance reports	Performance reporting	Project management plan updates
Approved change requests	Payment systems
Work performance information	Claims administration
	Records management system
12.4 Close Procurements — PG – Closing — KA – Procurement Management
Input	Tools & Techniques	Output
Project management plan	Procurement audits	Closed procurements
Procurement documentation	Negotiated settlements	OPA Updates
	Records management system

Story Point - Not an effort estimation

2012-07-09T05:56:00.002-07:00

I always use to think that Story Point is an effort estimate technique till the time I actually encountered and applied in project.

It is important to understand that Story Points are relative complexity estimates and not effort estimation technique. It is always RELATIVE and not ABSOLUTE. Let me explain in crisp.

Breakdown user stories to unit of relative size (small, medium, large, extra large....)

To compare feature relatively
Substitute to time

Story points are not a measurement of duration but simple measurement of size/complexity
Start with any standard feature and then other features(user stories) are 1X, 2X, 3X etc smaller or larger than that relative feature in size

Project Estimates - Cost, Effort, Schedule, Timeline, Team Structure

2012-06-27T06:48:00.001-07:00

How to estimate efforts for a project? This is a big question every time for many when they get new set of project requirement. Efforts estimation is not enough alone. We also need to do alignment and distribution of hours among the team and carve out the timeline and deliverable's for the project. I always use below simple format to calculate project cost, efforts, timeline, deliverable, effort distribution for dual/single shore mode. Easy and simple format where you can put everything at one place and can be used as a dashboard for management view.

Duration	Milestones	Deliverable	Architect Onshore	UX Designer	SharePoint Onshore Dev	DB Offshore Dev	Offshore Test	Total Hours
*Wk-1*	*Analysis*		40	20				80
	-Requirements Analysis	Functional Spec
	-User research	Design wireframes
*Wk-2*	*Planning*		40	40	20	40	20	*170*
	-Information architecture	Process flow Diagram/Site map
	-Finalize architecture	Development Specs
*Wk 3-7*	*Implementation Phase*		80	40	80	*400*	*200*	*880*
	-UI design	UI Frames
	-Backend Design	Demo -I
	-Workflow Design	Demo - II
	-Test Cases/Test plan	Test Plan
*Wk 8*	*User Acceptance*				20	80	40	*180*
	-User Documentation	User Guide
	-UAT Support	Helpdesk Support
	-UAT Sign off
*Wk 10*	*Product delivery*				20	40	20	90
	-Deployment Instructions	Deployment Guide
	-Deployment Packaging	Deployment Build
	-Code Hand Off	Code Database
Hours Total			160	100	140	560	280	1400
Rate			$	$	$	$	$	$
Estimated Cost			$	$	$	$	$	$

Project Gate Review Process

2011-07-21T03:41:00.000-07:00

I have always been asked by many people what is the best way to inculcate a good review process around a project to stenghthen the delivery process. This caused me to think and implement below Gate Review Process to my projects. Trust me, this process has resulted realy good outputs/results if followed religiously.

Problem Statement

Most of the project delivery goes through the critical path at the time of final delivery, and one of the reasons is observed that during the whole SDLC we are not reviewing the completeness of deliverables. This results in not identifying the risks at the right time and issues/rework at later stages.

Proposal

Gate Process: In a SDLC process, the whole delivery is divided into several phases. Each of the phases has pre-defined entry and exit criteria. For every phase, there is list of stakeholders who needs to review the progress of the last phase and decide to move to the next phase.

Rules and Procedure:

1. A Gate need to be approved before starting on next Gate

2. Gate Owner is responsible for arranging the Gate review meeting. Along with meeting request, he should send the list of deliverables for review

3. All the Gate reviewers must give their approvals/review comments either before (via email) or during the scheduled/planned meeting.

4. Gate Approver will take the final decision to approve/reject the Gate or passing it with Concession(with list of action items along with their closure dates)

5. A Gate can be approved with concessions (List of Pending Action Items with defined closure dates) but the next Gate can’t be approved, unless the concessions taken in previous Gate are addressed.

6. Gate Owner will publish the Gate Report on Close of Gate Meeting.

7. Every project plan should have these gates defined with planned dates and efforts.

8. In-case the Onshore PM/Offshore PM/ Development Head needs any tailoring in above process, due to project requirements, the concession for the same needs to be taken in G0 or G1 phase.

Gate	Gate Name	Owner	List of Deliverables	Gate Reviewers Mandatory (in Green), Approver(in Red) and Stakeholder (Blue)
G0	Project Sign Off	onshore PM	1. SOW/Scope Statement 2. Project Charter 3. Stakeholder Register 4. Project Site Locations	Onshore PM, Project Sponsor, Development Head, Offshore PM
G1	Project Kick Off	Offshore PM	1a. WBS/Task List 1b. Project Plan/Schedule 2. Signed Off FRS 3. RTVM 4. Team Allocation 5. Risk Assessment Meeting 6. Project Management Plan 7. Dev/Beta/Staging Refresh from Prod 8. Project Kick-Off Meeting (Full Project Team)	Development Head, Offshore PM, Onshore PM,Technical Lead, DBA
G2	Design Complete	Offshore PM	1. RTVM 2a. Approved HLD/LLD 2b. Process Flow Diagram(s) 2c. Data Flow Diagram(s) 2d. Wireframes, Samples/Mock-ups, Prototype(s)3. Updated Project Plan 4. Issue & Risk Register Updates 5. Test Plan 6. Design Review Meeting	Onshore PM, Offshore PM, Development Head, Technical Leads, DBA, Client
G3a	Coding Complete	Offshore PM	1. Updated HLD/TDD 2. Updated Project Plan/Schedule 3. Build Promoted to Beta 4. IT and System Test Scenarios and Test Cases Ready 5. Updated RTVM 6. Issue & Risk Register Updates 7. Code Review Meeting	Offshore PM, Development Head, Onshore PM,Technical Lead, DBA
G3b	Integration(Staging) Complete	Offshore PM	1. Updated Project Plan/Schedule 2. IT tested Build 3. IT Exit Report/Completed Test Cases(Dev team) 4. Updated System Test Cases 5. Implementation Review 6. Defect Tracking Sheet 7. Updated RTVM 8. Release Checklist(Dev team) 9. Issue & Risk Register Updates	Delivery Head, Offshore PM, ONSHORE PM, Technical Lead, DBA
G4	System Test Complete	Offshore PM	1. Updated Project Plan/Schedule 2. System Test Exit Report/Completed Test Cases 3. Updated Defect Tracking Sheet 4. Updated RTVM 5. Implementation Plan– Draft 6. Build Promoted to Staging 7. Issue & Risk Register Updates 8. UAT Preview	Delivery Head, Offshore PM, Onshore PM, Technical Lead, DBA
G5a	UAT Complete	Onshore PM	1. Updated Project Plan 2. UAT Exit Report 3. Updated Defect Tracking Sheet 4. Updated RTVM 5. Implementation Plan– Final 6. Final Build Promoted to Beta/Staging 7. Signed Release Acceptance Document 8. Updated Issue & Risk Register 9. Go/No-Go Meeting (Full Project Team)	Onshore PM, Client, Development Head, Offshore PM, Technical Lead, DBA, Project Sponsor
G5b	GOLIVE	Onshore PM	1. Customer Issue Tracker 2. Updated Defect Tracking Sheet 3. Updated Issue & Risk Register 4. Build Deployed to Production 5. Updated RFC Record 6. Project Close-Out	Onshore PM, Offshore PM, Development Head, Technical Lead, DBA

Project Control Book

To store and control the outcome documents of above given process and gates, a Project Control Book should be created as shared repository which will reside inside every project folder and will store the deliverables of every gate. The idea is to have the updated latest version of any deliverable available at a single location at any given point of time.

Rules to make the scrum product development successful

2011-07-21T02:35:00.000-07:00

Many people always look how to make their scrum projects successful. I am sure that these rules will help them a lot:

1. Identify Full-Time Product Owner
2. Product Owner Works With Team and All Other Stakeholders
3. Product Backlog Created and Managed by Product Owner

4. Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)

5. Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
6. Regular Sprint Length (no more than 30 days)
7. Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
8. Sprint Burndown Chart
9. Team Room with All Needed Equipment and Supplies
10. Retrospective Meeting for Process Improvements
11. Definition of "Done"
12. Commitment Velocity Calculated (from Sprint Backlog Estimates)
13. Team Size 7 +/-2, Maximum of 12
14. Cross-Functional Team Including ScrumMaster and Product Owner
15. Team Self-Organization - Team Members Volunteer for Tasks
16. ScrumMaster Tracking and Removing Obstacles
17. Team Safety - No Interruptions to Team's Work During Sprints
18. No "Break" Between Sprints
19. Sustainable Pace - Timebox Effort, Not Just Schedule
20. Quality is Not Negotiable - Defects Go on Top of Product Backlog

Project Management Methodologies and Software Development Process

2011-07-14T01:57:00.000-07:00

There have been a lot of software development process created over the years by different PM practitioners. In “Rapid Development”, most of the companies identifies a number of categories of process - most real-life projects employ a blend of these:

Pure waterfall
Code-and-fix
Spiral
Modified Waterfalls
Evolutionary Prototyping
Staged Delivery
Evolutionary Delivery
Design-to-Schedule
Design-to-Tools
Commercial Off-the-shelf Software

With the exception of code-and-fix, these processes have a few things in common – they assume that software development is analogous to a defined industrial process; they are based on physical engineering processes; they are predictive; and they assume that people can be treated as abstract resources. “It is typical to adopt the defined (theoretical) modelling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice”

In process control theory, a “defined” process is one that can be designed and run repeatedly with predictable results. In particular, the inputs to the process and the process itself must have very low levels of noise. When a process cannot be defined precisely enough to gurantee predictable results it is known as a “complex” process. Complex processes require an empirical control model. An empirical control model entails frequent inspection and adaptive response.

Software development is not a defined process, at the very least because the main inputs to the process activities are people. Traditional methodologies contain lists of activities and processes that are depicted as reliable and repeatable, however we all know from experience that this isn't the case. Ask two different groups of people to come up with class diagrams from the same requirements and you'll get two quite different results. The problems with treating software development as a defined process are discussed further by Schwaber and Beedle1.

Physical engineering processes consist of distinct phases. Thed esign phase is difficult to predictand requires creativity and imagination. The primary activities in the design phase are intellectual. The design phase is followed by planning for the construction phase, and then by the construction phase itself. The primary activities in the construction phase are physical, and it is much easier to plan and predict than the design phase. In many physical engineering disciplines construction is much bigger in both cost and time than design and planning. For example, when you build a bridge, the cost of design is about 10% of the total job, with the rest being construction.

For the analogy between software development and physical engineering to hold, we need to be able to separate design from construction, be able to produce a predictable schedule, design artefacts that are complete enough for construction to be straightforward, and be able to perform construction with people of lower skills (who are hopefully cheaper to employ). Construction also needs to be sufficiently large in time and effort to make this worthwhile. The situation in software development is quite different. The most of software development companies reports the following breakdown of software development by activity:

Analysis 16%
Design 17%
Code/Unit Test 34%
System/Integration Test 18%
Documentation 8%
Implementation/Install 7%

In an even more extreme analysis proposed by Jack Reeves - he suggests that code is analogous to an engineering design, and that software is “constructed” by running a compiler. Accordingly, the construction stage in a software development project is essentially free.

Regardless of the exact numbers, it's clear that as a percentage of the overall project effort, construction is much less significant in software development than it is in physical engineering. If construction is analogous to coding, our experience indicates that it's very difficult and expensive to

“Agile Software Development with Scrum”, Ken Schwaber and Mike Beedle, Prentice Hall, 2002
“The New Methodology”, Martin Fowler,http://www.martinfowler.com/articles/newMethodology.html
“Worldwide Benchmark Project Report”, Howard Rubin, Rubin Systems Inc., 1995
“What is software design?”, Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

produce design artefacts detailed enough for construction to be straightforward. If construction is analogous to compilation, then we can effectively ignore the construction effort. In either case, processes based on analogies with physical engineering should be treated with suspicion.