PoddarCo

Background

A software development project requires rolling out a new software application to a user base of 3000 people globally in the first phase, and then expanding to another 2500 users potentially. This application uses SharePoint 2010 and Office 2010 as its technical foundation. The software also relies on a virtualization solution provided by another vendor. The users have Office 2003 and Windows XP on their computers. The company has about 15000 employees globally; most using a combination of Windows XP and Office 2003 or Office 2007 on their computers.

Situation

A part of the project team set up a software lab with Windows 7 and other Windows 7 dependent software based on their research. As people started using the lab for testing, and issues emerged, Windows 7 got highlighted as a cause for concern, primarily because of –

• complications involved in upgrading everyone (user base and other employees) to Windows 7
• training concerns in transitioning users from Office 2003 to Office 2010
• integration issues with other legacy hardware and software
• the virtualization vendor’s Windows 7 ready solution being too late for our deployment goals

What if?

Had the team that set up the lab involved others in their decision making process from the start, they could have saved time, effort and money.  At least a couple options would have been to either start with a Windows XP solution and upgrade to a Windows 7 solution when the broader organization was ready or to communicate early enough any impact to the deployment timeline.

Often in software development projects, those close to the technology push to use the latest available tools or things that are “cool”. While I do not blindly discourage such endeavors, I can’t emphasize enough the importance to work with other department heads to ensure that the organization as a whole (and not just the software’s user community) can meet the demands of the proposed solution.

It is also important to consider if any other vendors you are dependent on will be able to complete their deliverables in time. The project referenced here used a Virtualization solution provider whose application would not be Windows 7 ready till June 2010. That timeline would delay the software deployment, which, from the very start was not acceptable to the sponsors.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Lately, quite a few non-project-managers and beginning-project-managers have asked me how to break into project management, or how to brush up on the basics of project management. By posting my thoughts through the blog, I thought I’d try to make the answer a little more collaborative. I have highlighted what are some must-have introductory skills, and stated at a high level some intermediate and advanced skills, which can be addressed further in future posts. These are still my work in progress thoughts; experienced project managers out there and beginners who have been through this phase recently, feel free to chime in with your experiences.

As the first step, I suggest understanding how a project traverses through its various stages, i.e. Initiation, Planning, Execution, Monitoring & Control and Closing; know what the goal of each phase is so you can better lead the team towards accomplishing that goal. I stress goal and not all the inputs, outputs and processes described by various methodologies. Regardless of whether you follow Agile, PMBOK, PRINCE or Waterfall approaches, projects follow a few basics: person-A dreams up a project for person-B to execute. Person-B needs to figure out how to organize the resources at his or her disposal to get the work done per person-A’s expectations. This entails reporting the vital stats at periodic intervals, and ensuring there are no loose ends. So read the theory behind what goes into a project’s beginning, middle and end, glean from that theory the practical insights that fit your environment and understand what your role is in facilitating the project through its life cycle.

Leadership, documentation and communication are probably three of the most basic skills needed to run projects successfully. From a documentation perspective, understand what are the needs of the project, of the team and of the sponsors. Some projects and sponsors will expect daily updates, others weekly. Some teams will warrant meeting and following up daily, others work better when left alone. Every project is different. This is where your leadership, communication and documentation intersect to produce what’s in the best interest of the project. At the least, know what goes into a project charter or some form of a project definition document, a status report, an issue log, a risk log and of course a project schedule. Familiarize yourself with the basics of risk identification, activity and resource scheduling, requirements capture and problem solving. Another important basic skill is being able to lead meetings whether they be weekly status calls, kick off meetings, client onsite discussions or steering committee calls. I have been quite surprised by how many PMs don’t know how to lead meetings effectively and efficiently.

IMO, intermediate project management skills focus on more elaborate risk management, issue management, team building, basic budget tracking, scope management, stakeholder management and facilitating proper project closure. Advanced project management includes budget control, detailed risk analysis, cost estimating, tracking project performance metrics through earned value management and other techniques, developing better forecasting skills and honing your project management style using a blend of best practices and methodologies. Check back again in the next few days for more posts on this theme. Btw, thanks to Soma B who unknowingly helped me get started on this series of posts…!

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

A new white paper titled, “A Project Manager’s Perspective: The Importance of Early and Thorough Requirements Capture” has been uploaded to PMI and PoddarCo.

To download the paper, please click the White Papers link on the top right corner of the screen.  If you are a PMI member, you can also find the white paper under Resources – Knowledge Shelf – Requirements Management.

Brief synopsis of the white paper:
The aim of this paper is to share a project managerial perspective on requirements capture. This paper proposes a requirements life cycle (framework) for better requirements ownership and management throughout a project. It highlights the iterative nature of requirements, calls out some of the basic misconceptions and suggests areas for risk identification (as related to requirements).

The key takeaways are driven home through a simple yet effective pasta salad illustration. The paper also includes some effective tools you can use instantly: 7 criteria for a high quality requirement, checklist of 7 potential sources of risk within requirements, a sample requirements traceability matrix and 7 simple lessons for better requirements capture and management.

Hope you find this material helpful and practical.  I would love to hear your feedback.  So please feel free to reach out to me via comments on this blog or via email at varunpoddar@poddarco.com

Regards
-V

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

As I was reading about risk management, I came across this research in Dr. Harold Kerzner’s book referenced below.  I followed his reference to the original source (also referenced below) - Dr. Edmund H. Conrow’s statistical analysis of survey results for fifty common subjective probability statements. 

Due to copyright limitations the original figure cannot be reproduced here; so I summarized some of my key takeaways from the study.  The figure below highlights how everyone can have a different interpretation of words commonly used to describe risks.  Not only does each statement communicate different probabilities, but also for each statement there is a relatively high variation in perceptions.  As Dr. Kerzner notes in his book, “an important point to grasp is that a nontrivial variation in probability (eg. 0.3) exists for more than half of the statements evaluated”.  

Lastly, I also found it interesting that statements like ‘likely’, ‘probably’ and ‘very good chance’ have a 55-85% probability range (the low end of this surprised me a bit).  The point of sharing this is that it is a great topic to bring up to your crew next time they use vague descriptions to denote the likelihood of risk.  It will help educate your teams and organization on the importance of using a common definition base or some consistent format to assign probabilities to risks.  

Just sharing something that I think is of tremendous value.  I have always wondered if someone could just tell me how likely is ‘almost likely’!  Thank you Dr. Kerzner and Dr. Conrow.  For anyone interested in exploring the observations of this study in more detail or in reviewing the original figures, I would strongly recommend reading the books referenced below. 

Different Interpretations of Risk Statements

References:
Conrow, Edmund H. Effective Risk Management: Some Keys to Success (Reston, VA: American Institute of Aeronautics and Astronautics) © 2000

Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Eighth Edition. John Wiley & Sons. © 2003

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

The title of this post was changed to “Where can you look for risks” to highlight an important point raised by Ricardo Guerreiro in a linked-in comment: risk identification is a collaborative process involving all team members. The earlier title could be misinterpreted as suggesting the PM should identify risks. Usually brainstorming works well for risk identification. A good place to start with is the set of requirements.

Looking for Risks?

For all requirements, list systems to be touched, applications or functional areas affected and stakeholders who requested the requirement.  Then, group the requirements across each category and prioritize them.  Look out for conflicting requirements from multiple stakeholders – this should alert the team to a potential political risk.  Look for interfaces needed with other applications or systems – this should alert the team to potential integration, timeline, resource and cost risks.  Similarly read across the requirements and between the lines to identify more risks.

Here are some other suggested areas to look into - 

• Licensing – are there any restrictions on usage of reference materials? Does any requirement mandate use of software that needs licensing agreements between vendors and suppliers?
• Legal, copyright and other notices – do any of the requirements call for legal disclaimers, warranties, copyright notices, patent notices, trademarks or logo compliance issues?
• Security, confidentiality or other standards – is there any data sensitivity or information sensitivity risk?  Are there any corporate standards or government-mandated standards to be aware of (Examples: ISO standards, Sarbanes-Oxley compliance, PMO guidelines)?
• Internationalization and broader application – can any requirement apply outside the immediate business vertical or functional area?  Does any requirement span a different geographic area or demographic?  Making a simple functionality accessible to someone in another corner of the world, or in a different language, can significantly alter the end-design and stretch project resources.
• Performance and scalability – can any requirement create performance issues, either from a user or system perspective?  Do any requirements lead to capacity or scalability concerns (Examples: load, storage, response time or efficiency)?
• Culture – can any requirement lead to a significant organizational or cultural change?  If so, executive sponsorship and proper change management will be instrumental to its acceptance and success.
• Training – can any requirement create more complicated training needs?  Will training be online or onsite, for how many users at a time and for how many users in total?

Click here to leave a comment (or click the speech bubble next to the title)