Strategizing On Shifting Left Security In The SDLC

#SridharPeddisetty #InformationSecurity #Security #Strategy #Social #Mobile #Analytics #Cloud #IoT #SMAC

“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” – Bruce Schneier

Introduction

Most of the Organizations still continue to have a reactive approach towards information security. In my earlier blog post 7 Reasons No Company Can Afford To Ignore Security, I had shared why Organization’s can no longer afford to ignore security and in 6 Steps Strategizing Security In An Organization shared on how to strategize security in 6 steps. Its important for organizations to have a proactive security strategy and have a shift left practice in software development lifecycle (SDLC) to focus on security right from the initiation state of a project. Integrating security in the SDLC helps in the accountability and increased communication with all stakeholders involved in the process to ensure the project is incorporating security policies while following the security guidelines. 

Why shift left security in the SDLC?

In the traditional SDLC, security strategy is always reactive in which the security testing is done at the end of development phase. If any security issues are found then, it becomes expensive to resolve and more often than not, due to time or financial constraints, quick patches are done or short term mitigations are put in place before releasing the software into production. More often than not, short term mitigations or patches result in costly expenses for maintaining security as the cost of operations are high. According to the study done by Cigital, cost of finding issues early during SDLC development phase results in upwards of 1165% savings when compared to finding issues during maintenance phase of SDLC.  

Strategizing on shifting left security in the SDLC 

Below is how we can strategize security by shifting it left in the SDLC. Incorporating security in each phase of SDLC helps an organization be more proactive in implementing a highly secured software. Moreover, overall costs are reduced as the security issues are found early in the development lifecycle. Security governance model established in the initiation phase helps define the security gates, policies, roles & responsibilities, timing of review, sign off process, etc. in each phase which governs security throughout the SDLC. Note that the Security Trainingis a continuous process throughout the SDLC so that the teams are constantly aware of security policies, protocols, tools, etc.

Summary

By shifting security left in the Software Development Lifecycle (SDLC), it helps in building more secured software and addresses the security compliance requirements while reducing overall cost. 

I will be sharing more inputs on Information Security including how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com

Strategizing On Shifting Left Security In The SDLC was originally posted under Prokarma Blog 

6 Steps Strategizing Security In An Organization

#SridharPeddisetty #InformationSecurity #Security #Social #Mobile #Analytics #Cloud #IoT #SMAC

"Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." — Gene Spafford (in e-mail to organizers of a workshop on insider misuse)

Introduction

For any organization, security is the collection of technologies, standards, policies, regulations and management practices that are applied to systems and respective data points to keep them secured. In my earlier blog post 7 Reasons No Company Can Afford To Ignore Security, I shared why organizations can no longer afford to ignore security. It's important for organizations to have a proactive security strategy in place for reasons inclusive of:

• Present business operations of an organization increasingly vulnerable to risk,
• Security threats from mobile & web interactions with corporate systems,
• Ever-expanding regulations, and
• International access points requiring organizations to be complaint with regulations and law of the land

  6 Steps Strategizing Security In The Organization

I will be sharing more inputs on Information Security including how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com.

6 Steps Strategizing Security In An Organization was originally posted under Prokarma Blog 

7 Reasons No Company Can Afford To Ignore Security

#SridharPeddisetty #InformationSecurity #Security #Social #Mobile #Analytics #Cloud #IoT #SMAC

"It used to be expensive to make things public and cheap to make them private. Now it’s expensive to make things private and cheap to make them public." — Clay Shirky

Today, technology is becoming core for any business and companies that are becoming more dependent on their information systems, with threats to public and personal data increasingly more real. To have an edge over their competition and with companies investing heavily on SMAC (Social, Mobile, Analytics & Cloud) and Internet of Things (IoT), they are exposing their business to new forms of information security risks. More often than not, companies have a very reactive approach to security in which there is minimal security strategy in place if none at all.

The following 7 reasons are important to understand and know that no company can afford to ignore security in today’s changing landscape of disruptive innovation with technologies and processes.

#1. Financial losses: Security breaches can lead to business interruptions, which directly impacts the financials of a company. An attack that leads to downtime for a data center can cost businesses nearly $8,000 per minute. Considering that the average downtime for each incident is almost 1.5 hours, companies stand to lose almost $700,000 due to downtime.

#2. Intellectual property theft: Even though companies are becoming better at protecting themselves from an outside threat, the view is that theft of intellectual property more often happens intentionally or inadvertently by the existing employees. Social media is the biggest medium through which free-flowing data leakage could happen. Phishing scams, whereby attackers try to elicit information from individuals, pose a significant threat as well.

#3. Damage to the reputation: In today’s world, reputation risk ranks among companies’ top strategic risks, and security is one of the primary drivers of reputation risk. According to The Reputational Impact of IT Risk

• 46% of organisations suffered damage to their brand reputation and value, as a result of a security breach and
• 19% of organisations suffered damage to their brand reputation and value, as a result of a third-party security breach.

#4. Fraud: General perception is that fraud happens mainly in banking and online retail shopping but the fact remains that all companies are vulnerable to fraud. Almost all companies use systems for online transactions, which are always vulnerable for attacks where hackers do major fraud. Unfortunately, today there is less protection for recovery of stolen funds under the law for businesses than for consumers, which makes companies more prone. 

#5. Extortion: Number of extortion cases are on the rise with extortionist groups threatening companies that their web sites would face a distributed denial-of-service (DDoS) attack if they do not pay ransom. Recent Ashley Madison data breach is an example of how a company can be extorted and the irreversible damage it could cause to the company and its stakeholders. 

#6. Loss of shareholder value: Highly publicized data breaches at Sony Pictures, Anthem Insurance, Ashley Madison and other major businesses continue to put loss of shareholder value at high risk. Ashley Madison CEO quit after the data breach, which caused a major loss of shareholder value. 

#7. Legal Implications through lawsuits: In recent times, companies have experienced possible damages due to lawsuits from security breaches and the overall loss of customers. The average cost for a legal defense stands at half a million dollars, while the average cost of a settlement reaches seven figures at one million dollars. Again Ashley Madison is a good example of the legal implications affecting the company. 

Let us not look back in anger or forward in fear, but around in awareness. — James Thurber

I will be sharing more information on Security including how to strategize and plan for Security, Risk and Compliance. Also sharing how to align Secured Software Development Lifecycle (SDLC) using Agile or Waterfall methodology and how security can be trained, initiated, planned, analyzed, designed, implemented and maintained. Meanwhile let me know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

7 Reasons No Company Can Afford To Ignore Security was originally posted under Prokarma Blog on Sep 8th 2015

Metrics For Maximizing Productivity In Kanban SDLC

#SridharPeddisetty #Agile #Kanban #SDLC #Productivity #BestPractices #Metrics #EngagementManagement

“Measure what is measurable and make measurable what is not so” –Galileo

In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban. In this post, we will look at the metrics for identifying bottlenecks while using Kanban as the software development lifecycle (SDLC) methodology. With experience and motivation to improve quality comes working out the right metrics, which measures areas of continuous improvements. In my earlier post 10 Ground Rules on the Right Metrics for Your Business, I had shared some rules on selecting the right metrics that is tied to the desired business outcomes. As summarized in the blog post, data collection, analysis & management is most often cost and labour intensive, so its important to always weigh in against the benefit derived from the selected metric.

One important principle of Kanban is to maximize productivity by optimizing the flow of work and managing work in progress (WIP) by removing bottlenecks. Before selecting the metrics, we need to assess what metrics is needed and then plan on using the processes and tools, which will provide the data for quantification in a shape and form that will allow us to measure. Presently Organizations are competing to provide faster value to their customers, which is effectively done by sizing and decomposing the requirements into minimal marketable features (MMF).

In Kanban, we can have have the Kanban board visualizing the WIP for states and swim-lanes. States could represent the following phases a user story (feature) or defect goes through the development lifecycle

• Product Backlog (Requirements)
• Defined (Analyzed) 
• In Progress (Development & Testing)
• Completed
• Accepted  

while the swim-lanes could represent WIP for 

• Expedite (Priority) user stories or
• Defects (Severity 1/2) or
• Different functional groups such as
  • Architecture,
  • UI/UX Designers,
  • Business Analysts / System Analysts, 
  • Development 
  • Operations
  • DevOps
  • QA
  • Technical Writers
  • others  

In some cases, Kanban board can represent one swim-lane for both expedite and non-expedite user stories or defects while just visualizing states.

Below is a sample ‘Cumulative Mean Lag Time’ metrics, which is measuring the time spent by a user story (USxxxx) or Defect (DExxx) both expedite or non-expedite in each of the following state

• Requested,
• Defined,
• In Progress,
• Peer Review,
• In QA, 
• In UAT and
• On Hold

From the metrics we can derive following information including identifying bottlenecks and areas of continuous improvement

• Expedite user stories (US7000 & US7674) are obviously prioritized by the team as the time spent in each state was short comparatively, thus faster overall cycle time. Information can be derived from the chart if the expedite items are distracting the team in effecting their WIP items by looking at the mean lag time an item is spending in each of ‘Defined’ or ‘In Progress’ or ‘On Hold’ states.  
• User story ‘US7626’ (second chart) was analyzed, developed, peer reviewed and tested in a short span (~2 calendar days) but spent ~9 calendar days in user acceptance test (UAT) state. One reason for this could be that the user story was not in the priority list for the stakeholders to be released or the priority lowered after the work started. As an opportunity for continuous improvement, we can look at the option where there is an opportunity to reprioritize the user story before the team starts the work.  
• User story ‘US7322’ (first chart) spent a lot of time (~25 calendar days) in ‘Requested’ state and then some time in ‘On Hold’ state (~12 calendar days).  As an opportunity for continuous improvement, we can work with stakeholders to make sure that we are getting the right requirements and acceptance criteria for the user story along with prioritization. The total cycle time for this user story could be also more because of the complexity and/or dependencies on the other integration deliverables. In either case, metrics shows the bottlenecks and provides an opportunity to optimize work flow for future such occurrences. 
• Above metrics also gives the overall cycle time for different sized user stories and defects, which helps in predicting for future work and ability to give a better commitment for the stakeholders 

Summary

User Story is like a fish, the longer its sits on the shelf, the less desirable it becomes. Use relevant metrics to measure lead time in each of the Kanban columns (states), which helps to identify the bottlenecks and to improve planning and forecasting. 

I will be sharing case studies, process improvements and best practices specific for Kanban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

Metrics For Maximizing Productivity In Kanban SDLC was originally posted under Prokarma Blog on Sep 8th 2015

Kanban & DevOps - Forming a Perfect Alliance

#SridharPeddisetty #Agile #Kanban #DevOps #Prokarma #KanbanDevOps #DevOpsKanban

Introduction 

"It is not the strongest of the species that will survive, or the most intelligent. It is the one most adaptable to change.” - Charles Darwin

As Organizations are going through a disruption phase including disruptive innovations with processes and technologies, there is wide adoption of Agile based transformation. In the context of the transformation, there is no better time of coming together of DevOps and Kanban, both of which enable Organizations to be more Agile in delivering services to their customers. 

What is Kanban?

Kanban is one of the lightweight Agile based methodology, which is based on Just-In-Time (JIT) software development. In Kanban based SDLC, the process from requirements of a task to its delivery to the customer, is visualized and team pulls work from a work item pool or queue. 

Kanban is based on simple 3 principles including

• Visualize Work In Progress (WIP)
• Limit the WIP
• Maximize Productivity (by minimizing lead time)

Engineering team does not have time constraints in Kanban while focus is on making sure the work keeps flowing by limiting maximum number of features or issues, which can be worked on at a given time.

What is DevOps?

DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle.

While the Engineering team remains focused on

• Analyzing,
• Designing,
• Coding 
• Testing and
• Production Support

of new services, the DevOps team combine together for

• Release management,
• Provisioning,
• Configuration management,
• Systems integration,
• Monitoring & control and
• Orchestration

of the new services

How Kanban & DevOps Match Perfectly?

Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. Basic principles for Kanban and DevOps remain common in terms of

• Collaboration,
• Cooperation,
• Communication, 
• Integration and 
• Automation

while bringing in transparency across the board. Managing a Kanban board provides the level of transparency in visualizing items in each of the work streams while formulating cooperation between teams by communicating dependencies, integration points and identifying items for automation.

A typical Kanban board could have items in following work streams

• Analysis
• Design
• Coding
• Testing
• Operations (Automation, Integration, etc.) and
• Production Support 

providing the visibility on high priority or expedite items while also sharing the respective status of to do, in progress or done items.  DevOps with Kanban maximizes the productivity with efficient delivery by 

• Reducing the overall cycle time of delivering services to end user 
• Identifying bottlenecks with items that are taking a long time in a work stream 
• Improved tracking of effort and associated costs
• Identifying recurring work that can be automated 
• Providing visibility to the end users of when services would be actually delivered 

Summarizing

Primary objective of Kanban is combining productivity with efficiency in developing services while primary objective of DevOps is to achieve continuous delivery by continuously integrating the services developed by the Engineering team and delivering those services with high quality. In summary, embracing Kanban and DevOps allow Organizations to introduce new services more often in a more stable environment. I would be sharing more information in next blog posts including best practices, tools and case studies corresponding to Kanban and DevOps. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com

Kanban & DevOps - Forming a Perfect Alliance was originally posted under Prokarma Blog on Sep 1st 2015

Inside and Outside Project Comparison and Prioritization

We understand the needs of a Project Management Office (PMO) to help drive IT efficiency, cut costs and improve the quality of project delivery in terms of time and budget. In my earlier blog 7 Questions to Ask Before Establishing a Project Management Office (PMO), I shared three types of roles a PMO plays in an organization in terms of supporting, controlling or directing. A PMO can boost productivity while ensuring that priority projects get the most attention, but it is important to perform the right comparisons between projects to prioritize them. The PMO should not be comparing 'inside' of a project in terms of which department/business unit the project belongs to with 'outside' of another project in terms of goals it's achieving. While reviewing projects, the PMO should go over the project charter or SOW, which includes:

• High-level scope of the project 
• Goals and objectives 
• Cost 
• Schedule
• Critical measures
• Potential gains
• Risks
• Assumptions
• Issues
• Dependencies
• Constraints
• Identification of key stakeholders
• Project's impact on the entire organization

Use a common basis for comparing projects while prioritizing them. One way of prioritizing projects is to group them in terms of:

• Business critical, strategic objectives or initiatives of the organization
• Business unit/department critical (one or multiple)
• Business unit/department need (one or multiple)
• Internal process improvements or exploring long-term growth by adopting new technologies and/or business models 

Note that the above mentioned grouping of priorities can change according to the strategic goals of an organization. After grouping priorities, there might be a potential need to do project sequencing for execution within each prioritized group. Harold R. Kerzner in his Project Management - Best Practices: Achieving Global Excellence book shares key decision criteria for project sequencing, which includes:

• Strategic priority
• Window of opportunity
• Project interdependencies
• Resource availability

Share your thoughts on how you compare and prioritize projects within your organization.

Inside and Outside Project Comparison and Prioritization was originally posted under Prokarma blog on Feb 26th 2015.

Why Active Listening is Key for Successful Delivery of Agile Based Projects

A man realized that he could not hear very well and that he had to buy a hearing aid, but did not want to spend too much money on it. So he went to the store and asked the clerk...

"How much do hearing aids cost?" The clerk responded "It depends, they run from two dollars to two thousand." "Let me see the two dollar model" the man said.

The clerk hung a string around the man's neck.

"Just put this button in your ear and stick this string in your pocket." "How does it work?" asked the customer. "It doesn't work, but when people see it on you they'll speak louder."

Actually our communication problems are not due to people speaking softly but mostly due to the fact that many of us are not good listeners. The biggest communication problem is that we do not listen to understand but we listen to reply. Presently you see more organizations acknowledging the importance that people want to be listened to, hence one company's motto: "We listen better” and another stating, "We hear you".

Agile development is more of an iteratively incremental approach in which requirements and solutions evolve through communication and collaboration between self-organizing and cross-functional teams. Agile promotes ‘building the right thing’ through customer involvement, adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid & flexible response to change in delivering high quality product or service.

Now since Agile encourages team to be cross-functional, most challenging aspect of a cross-functional team is the functional or technical silos, which often results in team deliverables ‘thrown over the wall’ between Architects, BAs, SAs, Designers, Developers and Testers. The problem here is not due to lack of coordination, but more due to lack of collaboration in which teams are not syncing on overall shared objectives. So for a cross-functional team to work as a collaborative unit, ‘Active Listening’ is the key in which each team is ‘listening to understand and not listening to reply’. Practicing the basics of ‘Active Listening’ includes:

• Focusing your complete attention to the speaker.
• Asking open-ended questions to gather elaborative information.
• Documenting gathered information in tool or a document.
• Getting the summarized information reviewed.

For any project, Risks, Assumptions, Issues and Dependencies (RAID) are very critical for its successful execution. Instead of making a lot of assumptions, ‘Active Listening’ helps us clear up many of the gaps when we detach emotions and instead pay focused attention to the speaker. Please share your thoughts on ‘Active Listening’ and how you think it's key for any project, but more for an Agile based project.

Why Active Listening is Key for Successful Delivery of Agile Based Projects was originally posted under Prokarma blog on Feb 12th 2015.

Are You Providing 'Right' Status of Your Project, Program or Portfolio?

A class teacher was posing questions to her second grade students as part of an assessment. She asked Tom, "Can you tell me a name of an animal that starts with the letter 'e'?" Tom replied "Elephant". The teacher asked him again but this time to name an animal that starts with letter ’t’ and Tom replied "Two Elephants". The teacher asked him the same question again and this time Tom responded "Ten elephants". Annoyed, the teacher asked him to name an animal that starts with letter ‘m’ and Tom replied "Mother elephant". By now, the teacher was getting very angry and repeated the same question. With a calm demeanor Tom responded "Maybe an elephant".

Syntactically it can be argued that Tom was giving the ‘right’ answers but they were technically wrong and certainly not the answers the teacher was expecting. Similarly, when stakeholders are asking for the ‘status' of a project, most often they are looking for how, when and at what cost (business value) the project will be delivered. The status report should not be just about status of scheduling, cost or scope but should be more of a report on business value. It is important to understand respective stakeholders objectives regarding the project, program or portfolio and the status report should be targeted accordingly. A dashboard summarizing the status on business value with respective links to elaborate on the specific status of scope, schedule and cost can be shared.

For instance, while executing Agile based projects it is important to understand the overall business value of the project. To understand business value it is important to first identify key stakeholders, respective goals, how to measure the goals and understand the relationship between various value drivers. Prioritized business value can then be mapped to respective themes or milestones, which helps in quantifying the requirements of overall business value while breaking them down in terms of incremental value. Overall status of the project can then be measured for each theme while sharing supporting status on:

• Velocity (actual vs. planned)
• Story Points (accepted vs. planned)
• Number of Defects 
• Percentage of Unit Test Coverage
• Number of Test Cases
• Number of Test Cases automated
• Percentage of New Test Cases Added
• Percentage of New Test Cases Automated

In my earlier post on 10 Ground Rules on the Right Metrics for Your Business, I discussed on how to select the right metrics. These posts can be used as guidelines for selecting metrics, which can then be included in future status reports showing progress on the business value of a project,  program or portfolio.

In summary, a good status report is an effective communication and transparency tool, which shares the progress on the business value of a project or a program or a portfolio mapped with objectives. What are your thoughts on providing the right status?

Are You Providing the 'Right' Status of Your Project, Program or Portfolio? was originally posted under Prokarma blog on Jan 27th 2015.

Comments: Some comments to the blog post are shared in google+  under https://plus.google.com/u/0/+JakeRahnerS/posts/62Es4z7rpm3

7 Questions to Ask Before Establishing a PMO

According to the definition in Project Management Institute (PMI) PMBOK Fifth Edition, the Project Management Office (PMO) is a management structure that standardizes the project related governance processes and facilitates the sharing of resources, methodologies, tools and techniques. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of one or more projects.

PMO is also applicable to program and portfolio management offices. By definition, program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually and portfolio is a collection of components (i.e. projects, programs, portfolios and other work such as maintenance and related ongoing operations) that are grouped together to facilitate the effective management of that work in order to meet the strategic business objectives. 

The PMO is established within an organization based on its strategic objective, in which it could play supporting, controlling or directive roles. 

1. In a supporting role the PMO is more consultative in nature. The goal is to provide templates, best practices, training, and a knowledge base including lessons learned from previous portfolios, programs or projects. The PMO's primary role is more as a document control center with a low level of control.
2. In a controlling role the PMO is more focused on auditing. This ensures portfolios, programs or projects are following recommended methodologies, best practices, standards, processes, etc. The PMO's primary role is to maintain compliance across portfolios, programs or projects with a moderate level of control.     
3. In a directive role the PMO is more management focused. Involved in the organization's portfolios, programs and projects, the PMO's primary role is identifying, prioritizing, authorizing, and managing with a high level of control.

So before establishing a PMO, it is very important to understand your organizations strategic goals. The following set of questions will help serve as guidelines

Question #1

What is the mission of the PMO?
Is the mission of the PMO to provide consulting services to projects, programs and portfolios running across an organization and/or to provide standards, processes, templates and also be responsible for auditing on a regular basis while flagging the projects, programs and portfolios that are not meeting their objectives and/or directly manage projects, program and portfolios while forming a governance framework.

Question #2

What are the roles and responsibilities of the PMO?
A well defined RACI matrix across organization will help determine the tolerance and maturity of organization to adapt to one of the supporting, controlling or directive PMO types.

Question #3

What would be the KPIs for a PMO?
How the PMO will be measured is important. Determine the type of PMO that needs to be established and set appropriate metrics accordingly. 

Question #4

What would be the 30-60-90 day implementation action plan to establish the PMO?
A step by step action plan of 30-60-90 days will help create short, mid and long-term goals for the PMO and help determine the PMO type as well.

Question #5

What is the governance model for the PMO? 
Managing and controlling the PMO for a longer period will depend on the governance model defined for the PMO. In turn, the governance model will help in understanding the type of PMO needed. 

Question #6

What is the availability of qualified personnel to staff the PMO?
Establishing a PMO is heavily dependent on finding qualified personnel and a key factor to be considered in determining the type of PMO.

Question #7

Where does the PMO fit in the organizational hierarchy? 
Understanding where the PMO will fit in the organizations' hierarchy will help establish innovators, early adopters, early majority, late majority and laggards. This will also help in planning the roll out of PMO in 30-60-90 cycles. 

Please share your thoughts on how you would establish PMO in your organization.

7 Questions to Ask Before Establishing a PMO was originally posted under Prokarma blog on Jan 6th 2015. 

Top 20 Tips for Project Managers

Project managers are responsible for the successful initiation, planning, execution, monitoring, controlling and closure of projects. According to the Project Management Institute (PMI), a project is temporary in that it has a defined timeframe, and therefore defined scope and resources. Also, a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. Project teams often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.

Project management is the application of knowledge, skills and techniques to execute projects effectively and efficiently. The following 20 tips (not necessarily in any particular order) are good references while managing a project.

1. Take good care of your project team and your team will take care of client, which in turn will take care of business
2. The project is all about delivery and keeping stakeholders (internal/external) informed
3. At any given point of time a project manager should know what tasks need to be done, who should do it and have an ETA
4. Always be on top of the RAID (Risks, Assumptions, Issues, & Dependencies) log as RAID is a critical factor for a successful project outcome
5. No plan is perfect so always have Plan B. Circumstances change frequently so always consider the alternatives
6. Projects are 90% planning and 10% implementation
7. Plan, Execute, Review and Adjust
8. Be adaptable and flexible while thinking outside the box
9. A good communicator is a good listener. By listening you may learn something new while speaking repeats what you already know
10. Always remember the 80/20 rule (Pareto Principle), which means by executing 20% of the work you can get 80% of the benefit
11. Break the whole plan into milestones and scope them accordingly including the development of checklists for each milestone to verify quality as project work incrementally iterates
12. Understand the dynamics of 'Definition of Ready' and 'Definition of Done'
13. Design a robust feedback loop to learn lessons along the way and strive to continuously improve
14. Negotiate achievable commitments by separating people from problems
15. You cannot manage and improve what you cannot measure
16. 6 P's of Project Management: Proper Planning Prevents Poor Project Performance (If i had 4 hours to cut down a tree, i would take 3 hours to sharpen the axe)
17. Get the right people involved including the experts you need and proactively seek guidance 
18. Trust but always verify. Direct communication is a key for forging trustworthy relationships
19. Plans are nothing; planning is everything. Planning is a continuous process including progressive elaboration or rolling wave planning
20. The difference between a good project manager and a great project manager are the leadership skills they possess

What are your top tips for a project manager? Please leave a comment to share your tips.


Top 20 Tips for Project Managers was originally posted under Prokarma blog on Dec 10th 2014