Great Minds Doing Work

Great Minds Doing
Work
A Review of the 97 Things Every Project Manager Should Know : Collective Wisdom
from the Experts
Matos
Matos, Dexter Brylle J.
PREFACE
This book was made to fulfill the requirements for my Project Management
class in De La Salle – College of Saint Benilde. All references are attributed to the
book, 97 Things Every Project Manager Should Know: Collective Wisdom for
Experts.
2
Dedication
This book is dedicated to my parents, whose unending love, care, and

support molded me to where I am now. A part of my love, appreciation, and
gratitude to you guys are expressed through the hard work I dedicated in
completing this book. I love you guys.
To my relatives, especially Anibeth, you all have always been there to

support and cheer me up, thank you.
To my high school batch mates and buddies for the special bond of
friendship over the years. The competitive spirit formed during our school years,
continues to motivate me to be better.
To my college friends and drinking buddies, whom I shared the nights with
booze and the days when we hanged out anywhere just to have fun and get away
from the cruelties of the world will always be memorable.
Finally, to the Supreme Being that gave me life in this world, to you be the
highest of praises.
3
Every Project Manager is a Contract Administrator
Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164
URL: http://pm.97things.oreilly.com/wiki/index.php/Every_project_manager_is_a_contract_administrator
Quote: “As the project manager, you are responsible for change control.” –Fabio Teixeira de Melo, PMP
What I expect to learn:
• The importance of managing change in a project.

• The different methods of containing any potential change that may bring risk to the project.
• The role of a project manager as a contract administrator.
Review:
As a project manager, contracts are very delicate between the firm and the client. Any
shortcoming to the fulfillment of the contract brings trouble not only to the project but also to the
reputation of the project manager and the firm as a whole.
Internal and external factors can and will play a role in the success or failure of a project. A well-
informed and functioning team is critical. A workshop about the different contract aspects, legality,
scope, rights, etc. may be provided for the team members. Initially, the details of a contract shall be
discussed by the project manager and the client/s. Discussion of the details shall/must be relayed to the
team members. Also, reminding them that any change or interference to the completion of the project
must be documented and relayed to the project manager.
Third parties should also be given a special emphasis, as they may be contacted be clients as
subcontractor and such event may bring confusion and eventually lead to some contract disputes. The
best way to deal with this kind of problem is avoiding it.
Customer/client satisfaction is always the primary basis of a project success. Change is good, but
managing and controlling it shall bring good results to any project.
What I have learned:
• Flexibility and a great skill of adaptability to change is a highly important skill a project manager
should possess.
• Relationships between different factors (internal and external) that may affect the outcome of
the project are as important as the relationship of the client and project manager/firm.
• Importance of the contract is equal to the importance of the success of project.
• Each member of the team must be well-informed of the different details of the contract.
4
Size Matters
URL: http://pm.97things.oreilly.com/wiki/index.php/Size_Matters
Quote: “The size of the project, the size of the team, the size of the deliverables, and the size of the
checklists – everything in a project depends on its SIZE. Size changes the rules of how the game is
played.” – Anupam Kundu
• In what different aspects does size affects the outcome of the project.
• The different ways to deal with different sizes of the project/team to accomplish the goal.
• The relativity of size to the project manager.
Review:
In this article, size didn’t solely refer to the size of the project. Size in a project involves the
different team members playing, different deliverables/modules, etc. When working with a large
project, it is important that the project manager should be able to breakdown different yet manageable
tasks/responsibilities to the team leaders. By doing so, it provides a clear picture to the desired goal.
From the article
Some key suggestions on how to carve out the size of the project and at the same time
manageable:
• Break down the project into as many independent, yet manageable work-streams as
possible
• If possible, try to have key members play overlapping roles in these work-streams so
that the “big picture” is shared across the teams.
• Document and share the risks, issues, assumptions, and dependencies of each work-
stream separately.
• Publish an overall project roadmap, including release plans from all different work
streams.
• Use online tools aggressively to share user requirements, milestone updates, bug
reports, report timelines, and risks.
5
• Breaking down the project into smaller, manageable modules would increase the efficiency and
accuracy of project realization.
• As much as possible, assign overlapping roles to team leaders so as to update each and
everyone of the progress of their assigned task.
• Document and share all aspects of every assigned module so as monitor the progress of the
different work-streams.
Integrative questions:
• What are the different functions of a work-stream?

• How effective can the chosen tools to document and update the progress of the project, to the
project?
• When the project is divided into different modules for the team, what factors(internal and
external) would affect its outcome?
6
Important not Urgent
URL: http://pm.97things.oreilly.com/wiki/index.php/Important_Not_Urgent
Quote: “You might not see the benefits immediately, but over time your team will spend more and more
time doing the Important, but Not Urgent activities that make or break the project.” –Alex miller
• The classifications of important and urgent tasks.

• How to manage the different classifications of important and urgent tasks.
•
Review:
The personal productivity classic, The 7 Habits of Highly Effective People by Steven Covey
presented four categories of activities, which are:
• Important and Urgent – Velociraptor attack

• Important, but Not Urgent
• Not Important, but Urgent
• Not Important, and Not Urgent
Among these classifications Not Important, and Not Urgent and Not Important, but Urgent are
the activities that should be paid less attention to. The former may be described as “slacking off” on the
job, and really does not help the progress of a project. The latter on the other hand, include the emails
and phone calls. These activities even though not important are considered to be urgent, and should be
kept to a minimum, and at best zero.
The Important and Urgent, are tasks that keep popping up on your desk as if nothing is being
done to accomplish it. The best thing to do with these activities is to create a “fallback loop” wherein if
the problem presents itself again (without any significant progress), it shall be rerouted to the “loop”
and would stay there until it is resolved.
Important, but Not Urgent activities should be given the most attention and focus to. These are
the activities that should be accomplished for the completion of the project. This is where knowledge
and value work and produce. Once these tasks are done, a better path for the success of the project is
laid.
7
• The different classifications of activities according to Steven Covey’s The 7 Habits of Highly
Effective People.
• Importance refers to the significance of a task; urgency refers to the tasks propinquity.
• Category 2 activities are the most important and should be given attention immediately.
• Category 3 and 4 are quite a waste of time and as such irrelevant.
• Category 1 are failures or problems that haven’t been resolved or toned down.
Integrative Questions:
• What is the Velociraptor attack in project management?

• Which of the tasks are considered to be the most important? Irrelevant?
• What are the differences of importance and urgency?
8
Get Users Involved as Early as Possible
URL: http://pm.97things.oreilly.com/wiki/index.php/Get_Users_Involved_As_Early_As_Possible
Quote: “Today, the secret to project success is to involve the user almost as soon as there is anything
visible to show them.”
“Costs for changes become increasingly high the further along we are on the project schedule
timeline.”- Barbee Davis, M.A., PHR, PMP Omaha, Nebraska, USA
• The importance of the users’ involvement in the project.

• Different penalties for excluding the users in the project/software design.
Review:
During the earlier days of project management, the times that the client and the project
manager would meet are during the giving of project specification and the software deployment. This
process caused for a lot of project failures and/or redesigning/recoding of the whole system to meet the
specific user need. Such changes would bring forth additional costs to the firm.
As a project goes deeper and deeper into its life cycle, the costs for its changes increases and
implementation of the project would be longer than its original/expected date.
In today’s project management “era”, project managers should inform the users as much as
something visible from the project is available. By doing so, this reduces the risk of redesigning and
recoding of the system after it has been deployed. It also helps that the users has something of a say to
the development of a project. This move shall be beneficial to both the client and the project manager,
in such a way that the clients gets the customer satisfaction from the firm as well as the firm reducing
and avoiding any potential additional costs brought about by some minor or unresolved issues during
the development phase.
9
• The clients/users should be involved as much as possible in the development of the

project/system.
• The involvement of the users during the development phase is crucial to the success of the
project.
• What are the different methods wherein the clients are involved as much as possible in the
project development?
• What are the different risks that should be alleviated?
10
Success is Always Measured in Business Value
URL: http://pm.97things.oreilly.com/wiki/index.php/Success_Is_Always_Measured_In_Business_Value
Quote: “We need to focus on the fact that the project is only as successful as the business value it adds
to the organization.” - Barbee Davis, M.A., PHR, PMP
• The value and relationship of the business to the project as it goes along its completion.
• The different aspects of business that may affect the relevance and completion of a project.
Review:
Project managers deal with a lot of things during the development of a project. They consider
the timeliness, cost, efficiency and effectiveness, and most of the time they tend to get caught up with
the aforementioned aspects. It is best not to forget to consider the business aspect of it.
Different projects have different business values in the marketplace. In a specific market, the
demand is closely considered as well as the competitors. But, if it is intended for internal purposes, the
project/software must be intended to cut costs and increase the efficiency and effectiveness of the
workplace.
Every project undertaking is an added cost to the company. And every company needs every
resource it has to stay afloat, especially when it is in a very competitive industry. Having said that every
project manager should take the following into consideration as he handles a project:
• The relevance of the project to the company’s well-being especially in the long-run.
• Will the internal project be able to reduce costs and/or make the processes inside the
firm run more smoothly and faster?
Remember, each project has a direct impact on the company’s longetivity and future. The
business value of each project should not be ignored or be put under the pile.
11
• Business value for projects differ in every purpose/market it is intended for.

• Business value shouldn’t be overlooked during the course of project development.
• Questions about the project would not be explicitly directed to you, ASK.
• What is business value?

• What are the different dimensions of business value?
• What are the different criteria to consider a project as an internal project?
• What are the things to always keep in mind so as not to overlook the business value of a
project?
• How can business value affect the project?
12
Start with the End in Mind
URL: http://pm.97things.oreilly.com/wiki/index.php/Start_with_the_End_in_Mind
Quote: “Well, there are a number of things to do first to increase the chances of delivering a successful
project. One of those things would be: start with the end in mind.” – Luis E. Torres, PMP
• The importance of a fixed mindset – the end, the success and completion of the project – would
greatly help the project and the team.
Review:
In a project’s life, having a mindset of the end-product will definitely help you have a positive
and highly motivated group of individuals. This kind of mindset will be helpful to avoid overlooking some
critical details from the start of the project.
Usually, project managers would like to draft the schedule of activities that needs to be done. In
doing so, some tasks may be overlooked and some redesigning must be done. A bad start was made.
Instead, kick things off with the Statement of Work (SoW). This contains the specifications and
requirements needed in the project. And within this specifications, it contains the ‘needs’ and ‘wants’
for the project. It is up to the project manager to identify and differentiate the said ‘needs’ and ‘wants’.
The right mix of attitude and individuals shall make the project a success.
Next up, is defining the scope. This includes of breaking down the work structure. By stripping it
down to smaller, workable modules, scheduling can now be done. Quality parameters must also be set.
Cost estimation must be the last item that will be defined. Constant control and monitor of the activities
must be done to ensure that everything is working in place.
13
• The right and positive mindset is a helpful tool for project completion and success.
• A positive mindset is contagious.
• Drafting a schedule should be done after the statement of work is broken down into smaller,
workable modules.
• How effective can the “start with the end” mindset to a project success?
• What are included in the Statement of Work?
• What are the criteria in differentiating the ‘needs’ and ‘wants’ in a statement of work?
14
The Fallacy of Perfect Knowledge
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Fallacy_of_Perfect_Knowledge
Quote: “Every day we hopefully learn a bit more about our profession, our society and ourselves. But we
simply can't know it all.” – David Wood
• The fact that there is no such thing of knowing all what goes in a project.
Review:
The Fallacy of Perfect knowledge is the assumption that the project manager or even the team
members know all of the things needed and the processes involved in the project. It is also the delusion
that it is possible to capture complete, non-conflicting requirements for a software project. It is also the
fallacy wherein, each and every individual involved in the project has a clear-cut list of requirements,
moreover, the meaning of requirement itself, which is really impossible.
Developers have been using the waterfall model to identify the requirements and eventually,
use it as a guideline during the project’s development life cycle. In this model, it is assumed that all of
the requirements have been identified (this includes the debugging, testing, and deployment stages).
The problem with this model is that user specifications may change during the course of
project/software development. To foresee the changes that may take place during the life cycle is
impossible and pure nonsense.
Methodologies such as spiral or agile gave up on the Fallacy of Perfect Knowledge and thus
embraced the idea that we might be able to know more after. These methodologies belong to Iterative
development, wherein the submission and completion of a project is more of a comma, rather than a
period.
Going away from the idea of knowing everything would help the project become more
successful, extensive and flexible.
15
• “The Fallacy of Perfect Knowledge is the delusion that it is possible to capture complete, non-
conflicting requirements for a software project”
• Giving up the notion of knowing it all and working along the “standard” requirements of the
project and at the same time being flexible to the fickle user requirements.
• The waterfall model, may present irregularities and inconsistencies at the end of software
development.
• The spiral model, iterative development proves to be the more practical methodology in
software development.
• What are the steps in the Waterfall model? Also, what are its advantages and disadvantages?
• What are the steps in the Spiral model? Also, what are its advantages and disadvantages?
• What is the Fallacy of Perfect Knowledge?
• What are the different methods that are prone to the fallacy of perfect knowledge? What are
the methods that are best to avoid the fallacy?
• Which steps are vulnerable to the Fallacy of Perfect Knowledge?
16
The Fallacy of the Big Round Ball
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Fallacy_of_the_Big_Round_Ball
Quote: “Picture a ball, manufactured to be perfectly spherical, perfectly smooth. The only design
requirement for this ball is that its diameter be exact when measured at any point. This ball is polished
and polished and polished some more until it is perfect. Once no defects can be found, all work on the
ball stops. It may not be changed. It is perfection.
Does that sound like any software project you have ever worked on? I didn't think so. Software just
doesn't work like that.” – David Wood
• The definition of Fallacy of the Big Round Ball.

• How the perception of perfect software reduces its usability and functions.
Review:
The Fallacy of the Big Round Ball is the delusion that software system requirements don’t
change appreciably after delivery or, worse, that they can be controlled.
During the course of a software life cycle, it undergoes a lot changes. Initial design decisions may
become useless once new user requirements have been ordered in the middle of the development
phase. Software is a malleable medium.
During the early years of software engineering, it is believed that if coding requirements would
be fully understood and finalized, therefore, a maintenance crisis would be averted. James Martin and
Carma McClure even suggested that a minimal to no user inputs of changes be entertained during the
development phases. This, of course, presented a lot of problems for the software, as to the familiarity
of end-users with the system. Also, when the software is delivered and deployed, it is always assumed
that the software is ‘perfect’. Thus, less technical support were considered at that time.
It is not impossible to create adaptive and flexible software. User inputs also serve as a great
ingredient for the best outcome of the software. However, dropping and forgetting the mindset of The
Fallacy of the Big Round Ball is essential. Having the wrong mindset would only drag the team down in
the long run.
17
• “The Fallacy of the Big Round Ball is the delusion that software system requirements don’t
change appreciably after delivery or, worse, that they can be controlled.”
• “We can design adaptable software, but only if we adapt our thinking first. Adaptability,
flexibility of design, and readiness for change should be the cornerstones of any new software
project.”
• What is the fallacy of the big round ball?

• What are needed to develop an adaptive and flexible software?
• What are the effects of limiting the users’ say on the project development?
• What are the reasons why software specifications change?
18
The Fallacy of Perfect Execution
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Fallacy_of_Perfect_Execution
Quote: “The building blocks of software don't snap together like Legos. They can be put together in so
many ways that it is impossible to determine all of the combinations.” – David Wood
• The fact that a universal logical flow exists, to which every programmer understands and
standardizes it.
Review:
The Fallacy of Perfect Execution is the delusion and belief that a flawless code with a very great
deal of attention to detail can be created. And software through time undergoes change and evolution.
New and better logic are being processed time and time again.
A solution or logic to software has different combinations. Each of it presents different process
and flow, also each presents its positives and negatives. Also, every programmer has a different
interpretation for every user requirements presented to them. So, it is really difficult for a new
developer to understand and continue unfinished software by a different developer. Different
developers also have different characters and attitudes. Documentation of a software depends on the
attitude of the developer, thus, incorrect documentation or worse, lack of documentation may present.
The only way to really unfold and analyze the algorithm of a program is by looking at its source code,
even then, this may also prove to be quite challenge because coding styles differ in every developer.
A perfect software does not exist as such a perfect world. A software, no matter how well it is
designed and executed will always contain bugs, glitches, and imperfections. These bugs or glitches are
to be discovered and be improved upon on. Also, the attitude and character of the developers also
affect the software, whether it’s in the documentation or the interpretation of the user
requirements/specifications.
19
• The Fallacy of Perfect Execution is the delusion that there is a universal logical flow that can be
understood by all developers.
• Different developers have different interpretations on the user requirements and/or
specifications, which makes each software hard to unravel during the debugging or testing of a
different developer.
• To really understand the logical flow of a software, look into its source code. But even then,
developers have different coding styles which make it quite hard to be in it.
• What is the Fallacy of Perfect Execution?

• Does developer interpretation really affects the outcome of the software? How?
• What is a sure method to process the logical flow of a program?
20
The 60-60 Rule
URL: http://pm.97things.oreilly.com/wiki/index.php/The_60/60_Rule
Quote: “We tend to pretend that software development is the most important part of the software
lifecycle. Development, however, is just not where the money is. ”
“The 60% of lifecycle costs related to maintenance coupled with the the fact that 60% of
maintenance activities relate to enhancements gives us the so-called 60/60 Rule, one of the few
proposed “laws” of software maintenance. “ – David Wood
• How the 60/60 rule help in software maintenance.
Review:
The common knowledge in the software life cycle is that, development is the most important
phase. However, it is not all about development. It is believed that, on average, 60% of the life cycle
costs come from software maintenance, and only 40% of it goes to development. The actual cost of
maintenance may cost from 40% - 80% of the total life cycle costs. The 60/60 rule refers to the
maintenance and the work implemented for changes or enhancements.
Migration, code changes, bug fixes all are activities under software maintenance. A good
maintenance plan, may command only 17% of the total maintenance effort. 30% of maintenance
revolves around the understanding of the code. New developers might took some time in really
understanding the code, especially if it is an old code or a code from a departed developer.
Software maintenance must be dealt with more attention. We have learned that from the
Fallacy of Perfect Execution that there is no such thing as a perfect software, rather, we should invest on
the continuous enhancement and fixes of what was initially done.
21
• The 60/60 refers to the maintenance and the work implemented for changes or enhancements.
• 30% of the total maintenance activities is devoted in understanding the code of the software.
• Software maintenance activities include bug fixes, program enhancements, migration, etc.
• What is the 60/60 rule?

• What are the different activities in software maintenance?
• What is migration?
• Why is understanding the code is crucial in software maintenance?
22
Clever Code is Hard to Maintain…and Maintenance is Everything
URL:
http://pm.97things.oreilly.com/wiki/index.php/Clever_code_is_Hard_to_Maintain..._and_Maintenance
_is_Everything
Quote: “Code that is too clever will ultimately be too hard to maintain. That leads to maintenance failure
and a costly reworking of your software systems.” – David Wood
• The different avenues of programming languages wherein the team can explore and learn from
it.
• The complexities of codes may be harder to maintain for later developers.
Review:
Most developers are stuck with old or legacy systems to work with. More often than not they
are expected to create “miracles” from these systems, thus, leading to some of them creating “clever”
codes that would benefit them in the long run, but not the project manager and/or the firm.
Clever codes are long, complicated lines of code that are used to maintain or enhance a system.
By having these clever codes, it is harder to maintain or enhance the system.
To avoid these clever codes, let the developers explore new programming languages that they
are comfortable with. If these languages can provide lesser lines of codes, it will benefit the project
manager and the company. It will be easier to test, maintain, and may also be self-defining. When
making these explorations into new programming languages, adept documentation must be strictly
observed so as to guide the future developers who will work on the system.
Therefore, simplicity and ease of accessibility to these codes must be followed, legacy or not, in
order for the easy and smooth maintenance of the system. It shall lessen the workload, cost, and time
spent on the maintenance of such systems.
23
• Clever codes are “evil” to the maintenance and enhancements of a system.

• Better programming languages and/or simpler lines of codes are essential in maintaining a
system.
• What are clever codes?

• What can be the worst case scenario wherein a system has too many clever codes?
• What are the ways to lessen or avoid the dreaded clever codes?
24
The Web Points the Way, For Now
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Web_Points_the_Way_%28For_Now%29
Quote: “Currently, we know of exactly one software architecture that scales to billions of users and does
so while being robust* to failures of individual components: The World Wide Web. The Web is the
largest, most used, and most robust information retrieval system ever built by humankind – so far.” –
David Wood
• The importance of the World Wide Web to future innovations.

• The basic principles that the World Wide Web is built on.
Review:
Nothing in the Technology industry especially in IT is constant. It is always changing. New trends
grow rapidly and exponentially. Everything is based upon innovation and improvement of a solid
foundation to ease people’s lives. And no one escapes the changing trends of IT, not even the world
famous, World Wide Web.
The World Wide Web is a very amazing innovation by the human race. It allows each and every
individual to actually communicate and see each other anywhere in the globe. It is also the most robust
architecture for information retrieval. It is very flexible and adaptive to changes. It uses lingua franca, a
universal language for transferring data and information. Also, its scalability is immense. While not all
use ‘lingua franca’, most of them do. The web’s flexibility allows developer’s to focus more on the
robustness, stability, scalability, and flexibility.
While all things must come to an end, the World Wide Web will serve as a stronghold for all
future architecture. As each development in the World Wide Web serves as stepping stones for the
future, systems being built now must also be flexible enough to adapt and immerse itself into future
technologies.
25
• The leading innovation in the IT industry today is the World Wide Web.
• The web is a robust architecture for communication and information retrieval.
• The web today shall serve as a steadfast foundation for future innovations.
• Flexibility and adaptability of systems today should be prioritized for the future.
• What is Moore’s law?

• What are the applications of Moore’s law?
• What are the possible innovations that can be produced from the web.
• How will the Apache and the Web in general influence future innovations?
26
Serve Your Team
URL: http://pm.97things.oreilly.com/wiki/index.php/Serve_Your_Team
Quote: ““Realize that one of the key roles of the project manager is to increase the team's velocity, and
to work towards creating a team environment with few inhibitors to productivity.” - Karen Gillison
• How can agile methodologies increase team productivity and the team’s morale.
Review:
What is an agile methodology? It is an evolving methodology which promotes a software

project management process that promotes shorter planning stages, adaptability and flexibility to
change, teamwork, and frequent user involvement throughout the project life cycle. In other words, this
is not your typical method of handling your team members, this is efficiency and effectiveness at its
best.
In agile methodology, the project manager usually kick things off with a simple meeting, giving
out assignments and discussing the project’s mission and goals. This engages the team members to a
proactive role, giving them the chance to be participative and be an essential ingredient to the project’s
success. Long meetings are absent in agile, instead the project manager establishes a “doorway”
wherein each team member is required to give timely status updates on the task they are assigned to.
These status updates shall be printed on the spreadsheet and be posted on the project manager’s
gateway. By doing so, this allows every team member and even the higher administrators to be updated
on the project’s status.
Utilize the agile methodology, and become a more effective project manager.
27
• Agile methodology is a method or technique in helping facilitate the team.

• Agile methodology is not a traditional method, instead, it utilizes each and every team member
to the fullest wherein, status updates are posted so as not to limit the progress within the team
members only. It also has a proper documentation, to be used for maintenance and reference.
• What is an agile methodology?

• What are the different positives that the agile methodology brings?
• What are the activities in agile methodology?
28
Aggressively Promote COMMUNICATION Channels While
Managing Distributed Projects
URL:
http://pm.97things.oreilly.com/wiki/index.php/Aggressively_promote_COMMUNICATION_channels_wh
ile_managing_distributed_projects
Quote: “Distributed projects create unusual challenges since the project team members are not
collocated (not physically together). As a result, the following issues can become impediments to the
success of a project.” - Anupam Kundu
• The proper facilitation of distributed projects.

• Communication between teams in a distributed project.
Review:
Distributed project means that teams are scattered in different geographic locations working on
one big project. A distributed project possesses a lot of potential and is high rewarding, but is not
without risks and problems. Communication is the major culprit in the failure of distributed projects.
Teams that are dispersed in different parts of the globe presents a lot of differences. A lack of
trust may bud from each team, cultural differences, web meetings that are untimely for some teams,
lack of team identity, and language barriers significantly contributes to a distributed project’s failure.
To tackle these problems, start off with getting each team member’s most convenient time of
the day to set up daily or weekly web meetings. Take into consideration the different culture in each
place. A standardized “dropbox” should also be established among teams so that every project artifact
may be accessed by anyone within the team in their own time.
After these time constraints have been regulated, the logistics of each team’s workplace now
should be managed. All communications equipments should be standardized and be of great quality.
Collaboration tools must be implemented, especially during meetings.
29
While there are many risks that are in a distributed project, it doesn’t mean that the project will
be a failure. Different solutions and compromises are present in the project manager’s disposal. The
main thing is, communication between teams should be healthy.
• Distributed projects are projects wherein teams are dispersed in different geographic locations
across the globe.
• Communication in a distributed project is the most important ingredient to project success.
• What is a distributed project?

• What are the different risks in a distributed project?
• Why is communication vital and critical in a distributed project?
30
9.7 Reasons I Hate Your Website
URL: http://pm.97things.oreilly.com/wiki/index.php/9.7_Reasons_I_Hate_Your_Website
Quote: “Most companies don’t know that software and web development differ, so software project
managers and software developers are asked to create websites.” –Barbee Davis, M.A., PHR, PMP
• Criteria that deter potential clients from visiting company’s website.
Review:
The following are reasons (according to Barbee Davis) that give negative feedback to a potential
client:
• Start off with a slow loading Flash screen
A Flash clip consumes a great deal of internet bandwidth during the loading process of a
website. Therefore, it is not really advisable for computers with slow internet connections. Plus,
most professional websites value the time spent of their visitors in the website, thus, directing
him/her directly to the main page.
• Surprise me with startling, ear-deafening video clips.
Audio from video clips must be modulated to a minimum before they are uploaded into
the website. Text is a better alternative.
• Disable the Back button
Back buttons are important to visitors as it provides an easier navigation of the website.
• Choose a low visibility color scheme
Color schemes are important to the fixture of the website. It must provide a readable
interface for the visitors.
31
• Ignore my portable devices
Website formats should be flexible to different web browsers. Most professionals

nowadays carry a smart phone or a PDA with internet connectivity. Since most of them are
always on the go, they also tend to browse websites on their smart devices.
• Provide no way I can reach a human by phone
Technical support details over the phone must be provided on the website, as some
people tend to be more comfortable when directly speaking to a company representative.
• Insist I call to get information
A website is made to be more informative than a phone service. Thus, all information
that is potentially needed by the customer must be present.
• Discriminate between customer types
This may refer to the compatibility of the website to older browsers.
• Include a useless search function
The search feature should be able to filter the different information queried by the user.
• Mislabel your buttons
Buttons should not lead to broken links.
• Different reasons dissuade a potential customer just by looking at the company’s website.
• Simplicity and functionality are keys to a good website.
• What are the reasons why potential clients veer off the company’s website?
• What are some standards in designing a good and clean website?
32
It’s the People, Stupid
URL: http://pm.97things.oreilly.com/wiki/index.php/It%27s_the_people,_stupid
Quote: “Your project’s success hinges more on team members’ attitudes and aptitudes than it does on
your Gantt chart wizardry and project tracking prowess. Feel free to manage the project, but don’t forget
to lead the team.” – Adrian Wible
• How to lead the team and manage the project at the same time.
Review:
To manage a team, the project manager must first learn to manage its team members. Each
person possesses a unique set of skills and talent, and their uniqueness also compels a unique way of
managing, not controlling, them.
Every team member is eager to contribute some way, some how. Each wants to be heard and
acknowledged. Acknowledging, guiding, listening to them are great steps to increase their morale, and
in return the team morale as a whole.
Regardless of the skilled and talented members, there will always be a poor performer in the
bunch. By using the CRAM (Constraints, Resources, Aptitudes, Motivations) model, managing a poor
performer would bring good returns not only in the project but also in the future projects as well. The
CRAM model also suggests that Motivation is the last item to be considered on a poor performer.
Constraints refer to the personal issues that a team member may have experienced or is
experiencing. This includes divorce, marriage, addiction issues, etc. Resources refer to the tools he/she
does or doesn’t possess. Examples are: Quality assurance test environment, or ancient hardware,
finances, or domain expertise (business analyst, end-user, customer). A poor performer may also lack
some aptitude in, say, database management. It is best that the project manager assign him to another
task that may fit his aptitude level. Motivation, must be the last one to address when constraints,
resources, and aptitude failed.
33
As a project manager, connect and mingle with your team members. Lead by example. After all,
you too, are a human being.
• Manage the team, not control them.

• Use the CRAM model if a poor performer is present in the team.
• Be one of your team members, connect and lead with them.
• Always inspire and motivate your team members.
• What is the CRAM model?

• What is the main principle on leading a team?
34
Engage with the Stakeholders Throughout Project Life
URL: http://pm.97things.oreilly.com/wiki/index.php/Engage_stakeholders_all_through_Project_Life
Quote: “Engage stockholders early and keep them involved through project completion. Be sure you
know the business need for the project they support. Work towards aligning the needs of all of the key
stakeholders, not just the top few.” - Lukeman Lawal, M.ENG, MNSE, R.ENGR. (COREN)
• The stakeholders’ influence and involvement in the project.

• The impact of the stakeholders to the project and vice versa.
Review:
Stakeholders may be individuals or groups, within or outside the organization, which may
influence the project’s success, and/or be impacted upon by the project.
During the beginning of the project a Stakeholder Engagement plan must be created. This
includes the following:
• Personal information of the stakeholder

• Assessment of their degree of influence
• Assessment of favorability towards the project
With this plan, it can be used as a strong support for the project. Engaging them throughout the
project life cycle is a good move and would build trust and relationship between the parties involved.
By creating this plan, it is easy to identify which stakeholders possess a bigger stake in the
project, which people show more commitment, and which of them may influence the stoppage of the
project. With this being stated, a stakeholder communication plan should be made. In this plan, it
includes the following information:
• The frequency wherein the team will contact the stakeholders

• The contents to be discussed in the meeting
• And the, when, where, and how are the meetings to be discussed.
35
With the stakeholder engagement plan and the stakeholder communication plan in place, it is
critical for the team to carefully consider the stakeholders’ indicator toward the project success.
Business value must be respected and be taken into consideration, regardless of any disagreements.
Confidentiality must also be observed, and keeping them updated is a MUST.
• The value of stakeholders in a project.

• The plans on how to deal with stakeholders.
• Who are the stakeholders?

• What are the different plans to be made for the team to get to know their stakeholders?
• What should be kept in mind when dealing with the stakeholders?
36
Can Earned Value and Velocity Co-Exist in Reports
URL: http://pm.97things.oreilly.com/wiki/index.php/Can_Earned_Value_and_Velocity_Co-
Exist_on_Reports%3F
Quote: “If you are new to Earned Value, it is a numeric tracking of progress and the business value of
that progress on a weekly, monthly, or quarterly basis. In an over-simplistic explanation, ignoring the
cost factors, the project manager (and other stakeholders) define requirements and estimate the amount
of time it will take to do the work of the project.” - Barbee Davis, M.A., PHR, PMP
• The definition of Earned Value

• The advantages and disadvantages of Earned Value
• Definition velocity and its relevance to time and schedule
Review:
The productivity of a team member or a developer is called, Velocity. To measure this

productivity, earned value is used as a metric that is recorded progress over time.
When schedules are set it solely based on estimates of the smaller modulated tasks assigned to
each team. Earned value is used to measure the progress of these tasks over a span of time. For
example, 40 tasks should be completed in 40 hours in one week. If they finished the 40 tasks by the end
of the week, they have 40 Earned Value (EV), and they planned it over for 40 hours which is the Planned
Value (PV). So EV – PV = SV (Schedule Variance). In this case, they have a total of zero SV.
If the team failed to finish the tasks in 40 hours, the succeeding tasks will be delayed thus every
team member must be notified. If they finish it earlier, then the succeeding tasks must also be started
earlier than the scheduled date.
This type of reporting makes the project development very flexible and keeps everyone updated
on their progress of the project.
37
• Earned value is a good metric to measure progress.

• Velocity is referred to as the developer’s productivity.
• What is Earned Value?

• What is Velocity?
• What are ways to increase Earned Value? Schedule Variance?
• How will this reporting style affect the projects scope and flexibility?
38
Don’t Skip Vacations for the Sake of the Project
URL:
http://pm.97things.oreilly.com/wiki/index.php/Don%27t_skip_vacations_for_the_sake_of_the_project
Quote: “Besides being the most visible position on the team, usually you are the only one in that role and
you don't have a backup. Planning time off is difficult, especially if you’re a third-party consultant. You
feel that your absences impact the project unfavorably.” – Joe Zenevitch
• Scheduling a vacation during a project.
Review:
Project management is a stressful job. As a project manager, you are alone and with no backup.
And thus, planning a time off is very difficult.
Novice project managers tend to cancel their vacations or worse, do not plan vacations at all.
Over time, a vacation is very much needed from a very stressful job.
If the project has a three-four week completion schedule, the vacation could wait. But if it is an
eight to twelve month project, taking a vacation in between isn’t bad at all. As the vacation is set, you
can assign a member from your team to be in charge while you’re out. Since he is from inside the team,
it is better for the project. It would be even better if the team’s analyst is assigned. Since he the person
with the most knowledge of the project’s requirements, scope, schedule, etc.
Another way of managing a vacation is by the concept of a self-directed team. A self-directed

team operates with clear and visible process without the involvement of a project manager. These kind
of teams take less time managing. It is quite difficult assembling this kind of teams, but it makes
vacation planning that much easier.
39
• Vacations are important for project managers.

• Vacations can be planned for.
• A self-directed team requires no direct involvement and constant management of a project
manager?
• Why are vacations important?

• What is a self-directed team?
• How to plan a vacation in the middle of a project?
40
Align Vision and Outcome Expected
URL: http://pm.97things.oreilly.com/wiki/index.php/Align_Vision_and_Outcome_Expected
Quote: “Software development projects are very challenging, because needs and expectations are not
always well-defined. The work of a software project manager is to make sure that this information is in
place. “– David Diaz Castello, MBA, PMP
• Awareness of all team members in the stakeholders’ expectations.
Review:
Software development may take different routes to its outcome if it isn’t handled correctly.
Developers have different interpretations of the given user requirements, and thus, may cause problems
and/or disappointment in the stakeholders. To have everybody on the same page, the project manager
must align the vision and outcome of the project.
For project managers, to align the vision and outcome, first off, the purpose and the reason why
the project is being developed is well-defined and understood by everyone. Also, the needs and
expectations must be stated in the requirements documents. Lastly, consider the impact of the 3P’s
(People, Process, and Platforms).
For the team, three dimensions must be tackled and understood, these are: Business view,
SMART view, and Subjective view. Business view refers to the opportunity the project is going to present
or how business value can be added to the company. SMART is an acronym for Specific, Measurable,
Attainable, Realistic, and Time-bound. This kind of strategy helps to create a very sound software. Lastly,
the subjective view, the team should gather all the perceptions and/or expectations from the end-users
during its initiating phase.
Aligning vision and outcome, reduces the misunderstandings between the team and the
stakeholders. Making sound and logical decisions on the fly is possible when everything is clear to the
team.
41
• The process of aligning vision and outcome of a project.

• The team should be well-versed in these three major areas: Business view, SMART view, and
Subjective view.
• Aligning vision and outcome of a project helps the decision-making of the team.
• What is the meaning of SMART?

• What are the effects of aligning vision and outcome to the team and the project?
• How can vision and outcome be aligned?
42
A Voice from the Other Side
URL: http://pm.97things.oreilly.com/wiki/index.php/A_Voice_From_The_Other_Side
Quote: “Software developers have now infiltrated the realm of non-profit and government sectors, with
promises of low-cost, web-based ways of doing business using fancy technologies that have heretofore
have been too expensive, too elaborate, and beyond the comfort level of our employees and
constituents. ” –Marty Skomal, MPA
The benefits of system development without introducing a scare from automation.
Review:
Today, many non-profit organizations still rely on non-automated systems to get their work
done. Meaning, they still use pen and paper to record and store data. Back in the day, automation by
software systems was affordable only by large companies or corporations. These days, non-profit
organizations are exposed and are able to hire developers and create automation systems for them.
Most developers tend to be overly excited when they hear that an organization or a company
would like to be automated. Non-profit organizations are flexible enough that they stick to paper-based
systems. With that being said, development should be done slowly, constantly interacting with the
stakeholders, wherein potential failures are within the toleration levels of control.
Not every task in the workplace must be automated. Simpler tasks must be left unscathed of
automation. By doing so, the organization retains its flexibility. While it is tempting to automate
everything, hearing the sentiments and concerns of the organization and stakeholders would bring
better customer satisfaction.
43
• Paper-based systems are popular in non-profit organizations due to their flexibility.

• Software developers tend to be over-excited on the prospect of automating a system.
• Over-automation scares non-profit clients.
• Why are paper-based systems popular in non-profit organizations?

• In what sense is flexibility present in a paper-based system?
• What are the advantages and disadvantages of automation?
• What can be earned and be lost in automation?
44
Chart a Course for Change
URL: http://pm.97things.oreilly.com/wiki/index.php/Chart_a_Course_for_Change
Quote: “New software changes the way in which people work. This may be good for the organization,
but the people who work there aren't always ready to embrace change.” –Kathy MacDougall
• A good change management program
Review:
Change management is a systematic approach in dealing with change, both in the organizational
and individual perspective. There are at least three different aspects of change management: adapting
to change, controlling change, and effecting change.
People naturally are indifferent to change. If new software is deployed, they are reluctant to
embrace that new software. They tend to ignore the positives of that new system. No matter how useful
and effective a software is, it is useless if no one embraces it.
The project manager should plan and focus on the procedures wherein his users are most
comfortable with. Slowly transitioning your members to the software is a good way to. Users who are
not motivated to use the software will be pointless and lose its potential.
After a comfort zone to the software is established by the users, it is important that the project
manager document the changes and thoroughly discuss it with the end-users. Giving special attention
on how they will react to the software is key. It is critical that both the management and the end users
agree with the changes.
During the development of the software, end-user involvement must be observed. They may
provide inputs to prevent risks and problems to the software.
After all is done, planning for the changes with the management must be done. They’re
knowledge of the company’s protocols would be indispensable.
45
• Change management must be carefully tackled.

• Not all end-users are “game” for change.
• Create a plan for change.
• Document the changes.
• The end-users are a vital key for the success of any changes.
• What is change management?

• How important are the end-users to the success of a new software?
• When is the right time to document and plan for the changes?
46
Roadmaps: What Have We Done for You Lately?
URL:
http://pm.97things.oreilly.com/wiki/index.php/Roadmaps:_What_Have_We_Done_For_You_Lately%3F
Quote: “Good communication inside and outside the project team is a key factor in the success of any
project. An important communication tool for all projects is the official project roadmap.” –Kathy
MacDougall
• The importance of a project roadmap
Review:
A project roadmap is an outline that helps the team, stakeholders, and the company complete
the project. In the team level, it helps the team to record and chart changes at the task level. For
stakeholders, it allows them to understand the changes that will happen on a higher level. The project
roadmap is a “vehicle” that communicates the planned changes, timeframes of changes, and most
importantly, the impact it will have on the business.
To create a roadmap, kick things off by inputting the top stakeholders. In the roadmap, analyze
which features are the most important and prioritized, and the importance of the availability of these
features on a given specific date.
Next is, draft the roadmap that shows a list of high level features segmented and grouped into a
realistic timeframe. If a feature can’t be described, its validity is questionable. Thus, features without
tangible business values must not be included in the roadmap and must be further analyzed by using the
cost / benefit analysis.
After the draft is created, get feedback from project sponsors as well as from the stakeholders.
Feedbacks should include both positive and negative comments about prioritization, value, clarity, and
concerns. If items are missing in the roadmap, alert the team.
After the roadmap is created, post it in the project website, present it to the higher ups and
utilize it as the primary communication tool for the project. If there are changes and delays, recreate the
roadmap and share it to everyone involved.
47
• A project roadmap is a chart which defines the specific changes that the software will bring to
the organization within a given timeframe.
• A project roadmap contains the different features of the software along with its corresponding
value.
• What is a project roadmap?

• What are the steps in creating a project roadmap?
• How is a project roadmap helpful in managing the team, stakeholders, business, project?
48
Documents as a Means, Not an End
URL: http://pm.97things.oreilly.com/wiki/index.php/Documents_as_a_Means,_Not_an_End
Quote: “Successful project managers understand how to reap the benefits from planning without the
overhead of meticulously updating their plans in minute detail. They actively use documents to help
spark meaningful conversations, not as the replacement for all communication methods. Or worse yet,
use documents as a way of pointing out when people breach an agreement.” – Patrick Kua
• Documents possessing a lesser role in a project
Review:
In the early phases of the project, specifically the planning stage, it is a must that a document
must be created to record schedules with their corresponding tasks. While they may hold a somewhat
significant value, it is not saying much because plans invariably change over the course of the project life
cycle. And revisions to the original plan are inevitable.
There is a misconception by many organizations that documents are used to track the progress
of the project. Most of them require a rigorous documentation process of the project, which really is
inaccurate. Documents are used for plans, revisions or changes, issues, but not as a tool to track
progress.
While, documents are essential in achieving different organizational and project goals, it is
impractical and ambiguous to rely on them for tracking progress.
• Documents present an undeniable value, but must not be used as a tool to track progress.
• Plans invariably change.
• Fallacy: documentation is a progress.
• What is documentation?
• What are the importance of documentation?
49
You are Not in Control
URL: http://pm.97things.oreilly.com/wiki/index.php/You_Are_Not_In_Control
Quote: “Actively seeking control sometimes creates the opposite effect. An experienced, well-formed
team will actively shun a person trying to take control for personal reasons, especially if that control
brings little benefit to the team.” – Patrick Kua
• The value of leading a team not controlling them.
Review:
Leading and controlling a team are two different things. The latter being the most detrimental
and most ineffective in managing a team.
Understanding group dynamics and different leadership skills are key to successfully leading and
managing a team. Well-formed teams need not much control, while newly formed teams need more
guidance and supervision to direct them in the realization of the project objectives.
Project managers must know when and how much control will be exerted to his/her team while
also recognizing and maximizing the skills, talents, experience, and connections each team member
possess.
• Leading and controlling are different concepts.

• Well-formed teams need not much control or supervision, while newly formed teams require
more guidance and direction to the accomplishment of the objectives.
• Control, especially too much control is not good for the team.
• Knowing when and how much control must be exerted to the team.
• What is the difference between leading and controlling a team?

• What can be the negative effects if too much control is pushed into the team?
50
Pay Your Debts
URL: http://pm.97things.oreilly.com/wiki/index.php/Pay_Your_Debts
Quote: “In the world of software development, borrowing time can be a useful strategy for meeting “at
risk” milestones, while completing most of what needs to be done.” – Brian Sletten
• Debt as an advantage
Review:
Debt in software development means, “quick fix”. This is usually exercised to a feature when it is
close to a presentation to stakeholders. It is also referred to as a “technical debt”, or borrowed time,
because of its non-monetary value.
Technical debt is good if it is managed responsibly. However, if it piles up, it puts the project at a
very high risk.
The best way to pay off these technical debts is by assessing the “loans” made after each
iteration. Ask the developers to look for hacks and quantify how much they need to repay these debts. It
is not necessarily to required to pay it back in one big payment, rather they need to gauge the extents of
the needed repair.
There are a quite number of software tools that can be used to find and identify when were the
loans incurred. Such tools include: code coverage, coupling analysis, and detecting different styles of
deviations. Balance out the workload between business functionalities and paying off loans. In this
manner, debts are kept in check to prevent them from spiraling out of control.
By identifying debts early and at the same time dealing with it quickly, little by little the
technical debts are being paid off and which will ensure the prevention of chaos.
51
• Technical debt buys the team more time.

• Technical debts are unpolished code that are quick-fixes to a feature for an upcoming
presentation.
• Too much debt will slow down and put the project in risk.
• Debts should be paid off as early as possible while they are still fresh in the developers’ minds.
• What is a technical debt?

• What are purposes of a technical debt?
• What are the ways to effectively pay off debts?
• What are advantages and disadvantages of incurring a debt?
52
Software Failure is Organizational Failure
URL: http://pm.97things.oreilly.com/wiki/index.php/Software_Failure_is_Organizational_Failure
Quote: “Developing software requires valid metrics, clear communication, and engaged business and
executive stakeholders. They must be involved in software delivery efforts and assume partial
responsibility for both positive and negative outcomes.” – Brian Sletten
• Software failure does not solely fall on developers’ hands.
Review:
When there is software failure, all hands are immediately pointed to the faces of the
developers. That may be partially correct since they are the ones who develop, code, test, and debug
the software projects. Reasons for this vary from lack of skills, training, motivation, or inadequacy of
developing quality software. However, the developers are not the only ones who are at fault for every
software failure. The organization as a whole is also responsible for any project failure. Developers and
the organization are co-dependent to each other.
Software failure may stem from lack of communication and coordination to the developers from
project managers, or the organization as a whole. Lack of communication, more often than not produces
bugs, glitches, misunderstanding in the user specifications, large incurred technical debt. To resolve this
kind of failure, the organization should invest on the teams’ development and needs throughout the
project life. Thus, motivated and more productive developers are in the organization’s disposal.
53
• Developers are not the only one to blame during software failure, organization too.
• Organizations are as reliant to its developers and vice versa.
• Lack of communication and coordination usually results in software failure.
• Negligence to the developers’ needs is a factor in software failure.
• Initially, who are the ones to blame in the event of a software failure?
• What are the shortcomings of the organization to the developers that results in software
failure?
• How can organization strengthen the co-dependency of both parties (organization and
developers)?
54
Project Management is Problem Management
URL: http://pm.97things.oreilly.com/wiki/index.php/Project_Management_Is_Problem_Management
Quote: “We’re here because executing a project is an inherently messy business and individuals with our
unique skills and temperaments are necessary to ensure that the inevitable difficulties get squashed,
circumvented, or massaged into non-issues. ” –Lorin Unger
What I expected to learn:
• How different problems concern the project manager.

• How project management is problem management.
Review:
Project management doesn’t end and start with project moving, getting the software done,
adding business value to the firm, etc. These are not only the core activities of a project manager. And
project management is so much more than that.
Problems are natural to occur in a project, and managing these problems is project
management. Smoothing the different bumps and complications that arise in a project are included as
tasks of a project manager. The definite role of a project manager is plan better, think more clearly, and
have a more strategic vision compared to those who sponsor the project. In simpler terms, project
managers need to be one and a half step ahead of everyone. And overseeing problems, major or minor,
is a must.
Be prepared to accept the fact that there will always be detractors to the project. Be it
stakeholders, higher ups and the like. Adapting would be the best way to counter their negative
attitudes.
While being upset on a setbacks and complications are normal, it is important to remember that
these are part of the job and the project manager should focus on solving and working around these
trivial problems.
55
• Project management does not solely mean the planning and development of a project, it is also
the management of problems and complications that go along with it.
• There will always be detractors and negative people around a project, it is best to adapt to them
and don’t let them affect the realization of the objectives.
• What are the different problems that may rise in a project management?
• What is project management really about?
• What are the different typical attitudes of negative people on a project.
56
Under-Promise, Over-Deliver
URL: http://pm.97things.oreilly.com/wiki/index.php/Under-promise,_over-deliver
Quote: “At the end of the project, deliver less than you said you would and you are a bad software
project manager. Deliver more than you said you would and you're the hero. Actually, you should strive
to deliver exactly what you promised. No more, no less.” – Joe Zenevitch
What I expected to learn:
• Promised features and deliveries
Review:
New project managers tend to impress his/her higher ups by accepting additional features that
the client suggests. Business clients often perceive this that PM has it under control and will eventually
be impressed. But as project life progresses, technical debts have piled up and it is impossible for the
promised features to be delivered to the client. The once impressed customer, will now burn in fury, and
may terminate the project, more so, terminate the project manager of his job.
On the other hand, experienced project managers provide a prioritization list according to its
business value. The PM explains to the business client that features at the bottom of the priority list are
less likely to be delivered and included in the release. At first, these clients may get annoyed and
irritated, but as the project life moves on, they accept the fact that not all features may be rammed into
a system.
It is expected that changes shall come and go in the project life cycle, and a contingency plan
was created, known only by the project manager and may not even be revealed to the client.
In the final days of development, if contingency still serves, the features that are less prioritized
may be now pushed into the software as a bonus. Now, both the project manager and the client are
extremely happy for a job well done.
57
• It is foolish and stupid to keep accepting features from clients and commit in developing all of
them.
• A priority list of features based on their business value must be created.
• A contingency plan must also be created.
• The contingency plan must be kept secret and away from the clients.
• Why is it unwise to commit to many features?

• What is a priority list?
• Why must be the features in the prioritization list be based on business value?
• What is a contingency plan?
• Why must be the contingency plan be kept a secret from the clients?
58
Use a Wiki
URL: http://pm.97things.oreilly.com/wiki/index.php/Use_a_Wiki
Quote: “Wiki's are a great mechanism to centralize access to your project information. Hopefully, the
wiki will be updated multiple times daily and will always be open in a window on a team members'
desktop.” – Adrian Wible
• The uses and benefits of a Wiki.
Review:
A wiki is a great tool to centralize all information regarding the team and the project. It provides
a unified coordination and communication medium for the team and its members. The following are
useful ways to organize a wiki:
o Stakeholders – this space is intended for topics regarding the latest project status, short
and long term issues, budget-tracking and milestone achievements
o Developers – a page dedicated to the resources and required standards. Coding
standards, database queries, dependencies and common mistakes.
o General Information – basically an address book of the team members. Contains basic
information and contact numbers. A help desk number should also be included.
o Team Calendars – an embedded calendar API or tool will be useful. This will show the
meeting schedules, integration dates, even vacation dates.
o Meeting Minutes – this page would contain the highlights of all previously held
meetings, which should include: topics/agenda discussed, issues discovered and
resolved. This will help refresh the members’ memory of tasks and milestones.
o Meeting Agenda – page dedicated to the stakeholders who want to have a meeting with
the team. Subject to project manager’s approval.
o Business Analyst – dedicated to project artifacts and the like
o Testers – user information of testers outside of the development team. Must contain
testing methods and procedures.
59
Maintaining the wiki is the team’s responsibility, but cleaning up information is the project
manager’s job. The wiki must also be regularly updated or it is rendered useless.
• The definition of wiki and its uses.

• The steps on setting up a wiki for the team.
• The content of the wiki.
• Different content and usability of different pages.
• What is a wiki?
• What are the proper steps to create an informative wiki?
• Who needs to maintain the wiki?
• Who is responsible for the stream of information that is posted and removed in the wiki?
60
The PMBOK® Guide is not the Holy Bible
URL:
http://pm.97things.oreilly.com/wiki/index.php/The_PMBOK%C2%AE_Guide_is_not_the_Holy_Bible
Quote: “Many Project Managers get overly involved with following a methodology to the detriment of
managing a project to a useful, praiseworthy completion.” – Fabio Teixeira de Melo, PMP
• References and textbooks may be a problem to the actual application.
Review:
Project managers obviously have a wide range of skills for managing projects. A lot of books are
dedicated solely on project management simply because of the difficulty involved with managing a
project. While it would be a good idea to apply these references in real-world projects, it would be a
terrible idea to enforce them.
Not all project management processes are familiar to all team members. It’s subjective to the
team members’ backgrounds. Therefore, mandating a particular process learned from some reference
book would take considerable time, effort and money. It would be great if they were somehow familiar
with it, but to dedicate so much time to master such processes would considerable slow down the
project especially if it’s not sanctioned by the organization.
Another issue is the company culture. Some practices might clash with the company’s
established culture especially if the company in question is a foreign one. Some project management
processes will simply not mix with some cultures. Even if the company is not foreign, some project
management practices are at the mercy of the company’s established practices. This will not do
especially if the project manager is new to the company or was outsourced.
61
Textbook references, or any reference that help in project management for that matter, is not a
complete waste. There are many things to be learned from these books, but project managers should
not expect the team to have mastered these references as well. References should be a tool, not a
deliverable.
• References are to be utilized not to be mastered by every team member.

• Applying the knowledge to the team is better than forcing the team to learn it too.
• What should be some guidelines when applying what is learned from textbooks?
62
Favor the Now Over the Soon
URL: http://pm.97things.oreilly.com/wiki/index.php/Favor_the_Now_over_the_Soon
Quote: “We can plan the software. We can discuss the features it will have. But software that you can
touch, run, and interact with is a million times better than a Word document full of requirements. ”
–Scott Davis
• The importance of a “tangible” software compared to a document of requirements.
Review:
In the software industry, there is this vaporware phenomenon, a software that is endlessly
talked about, got everyone excited for it but in the end, is never actually delivered. It may be stated that
these vaporware are patterned from the waterfall model. The waterfall model is a step-by-step process
in systems development. This model presents more disadvantages than advantages. First off, coding is in
the fifth step. Debugging and testing occurs late in the model. If any major problem occurs, there is little
time to fix it before its delivery. It can also be said that a failed test, is in a way a failed project.
In order to avoid this, iterative development must be utilized. Iterative development is a method
wherein the development of the software is presented with prototypes along the project life cycle.
These prototypes would serve well as they will provide sufficient test results that will improve the
software. Each prototype is better than the previous, based on the test results and user feedback.
Iterative development provides more time to improve the software.
63
• Vaporware is a software that doesn’t come into fruitition.

• Waterfall model presents many disadvantages when a major problem occurs in the
development of the software.
• Agile method is the iterative method.
• Iterative method provides more opportunities to improve the software as it contains a lot of
prototypes that improves after every testing.
• What is a vaporware?
• What is the definition of a waterfall model?
• What are the advantages and the disadvantages of a waterfall model?
• What is the definition of iterative methodology?
• What are the advantages and the disadvantages of a iterative development?
• Why is iterative development more effective than the waterfall model?
64
Favor the Simple over the Complex
URL: http://pm.97things.oreilly.com/wiki/index.php/Favor_the_Simple_over_the_Complex
Quote: “No one ever starts out with the goal of making a product that is unnecessarily complex. The
complexity comes along accidentally. ” –Scott Davis
• Simple software is better than a complex software.
Review:
Gathering and collecting of requirements from the users is a tedious task. They may usually give
out contradicting requirements, and the project manager may give it directly to the developers. This is
called, complexity amplifier.
True to its name, complexity amplifiers further the intricacy of the requirements by pushing it to
the end-users. Redundancy of buttons with little to no variability of functions, and having too many
steps to perform a simple task are some of the attributes of a complexity amplifier. Analyst that fails to
thoroughly analyze and decode the software requirements are complexity amplifiers themselves.
The sole purpose of developing a software is to simplify the tasks that it was created for, not to
further cause any complexities.
65
• Complexity amplifiers are software that confuses and burdens the users instead of providing aid.
• Complexity can be traced back to the gathering of user requirements.
• Analyst themselves are complexity amplifiers if they fail to thoroughly analyze the requirements
and specifications.
• Simplicity of software is the main purpose of developing a software.
• What are complexity amplifiers?

• How are complexity amplifiers created?
66
Developer Productivity Mean vs. Median
URL: http://pm.97things.oreilly.com/wiki/index.php/Developer_Productivity_Mean_vs._Median
Quote: “Understand that really good software developers are much more productive than average ones.
In fact, some statistics say that really good developers are multiple orders of magnitude better than poor
ones. One order of magnitude is the same as multiplying a quantity by 10. The point is, a skilled
programmer isn’t just a little better than an average one, the difference is huge. ” – Neal Ford
• The difference between an average and a skilled programmer
Review:
In today’s software development, what is developed today will serve as the foundation for the
future of the industry. Having mediocre developers would slow down a project. Good developers would
need to go back and fix the flaws and glitches before progressing. Having mediocre or average
developers slow down the project velocity. Sacking a mediocre developer is better than hiring a good
one.
Non-experienced project managers would hire or add more men to the project, with the reason
behind that more people hasten the project. This is not entirely or not true. It would only slow down the
project. Chemistry is important in a team. Adding new guys/gals would increase the communication
channels and would affect the pace of the project.
To solve this dilemma, hire good developers. Give them powerful tools to work with and you’ll
see quality software be created faster than a team of average developers that would develop an
average program. Spent the extra money to invest and nurture the excellent developers. Results would
be evident both in the short and long runs.
67
• Hiring additional average developers to increase the project velocity is a fallacy. In fact, it will
only slow down the project.
• Invest and nurture excellent programmers. Results will pay off both in the short and long runs.
• Pulling an average developer off the team would be better than adding more good developers.
• Which is better hiring additional good developers or sacking mediocre to average developers on
the team?
• What are the myths about software projects?
• What are the different factors that may slow down a software project?
• What are some ways to increase team and individual productivity?
68
Savor Sustainable Progress, not Speed
URL: http://pm.97things.oreilly.com/wiki/index.php/Savor_Sustainable_Progress,_not_Speed
Quote: “When measuring time for a feature implementation, do not consider only the time it takes to
write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good
quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term
gain. ” – Venkat Subramaniam
• The benefits of speed compared to quality

• Rushed code vs. Sustainable code
Review:
A software project has many deadlines, especially when using iterative development. Speed is
the top priority.
A rushed code and a sustainable code have similar external appearance. A rushed code
however, contains an unstructured code which makes it susceptible to errors during maintenance and
revisions. A sustainable code, on the other hand is the exact opposite. Methods, classes are well defined
and are very structured. Sustainability is the ability to be debugged and improved smoothly.
In an iterative development, change is constant. Therefore, codes must be structured and easy
to read to enable developers to fix or change any desired feature.
Sustainable codes may seem to be a short-term loss, however, it travels with a very
SUSTAINABLE gain in the long run.
69
• Sustainable codes are easier to manage than rushed codes.

• A rushed code provides short-term gain, a sustainable code on the other presents a long-term
gain.
• What is a rushed code?

• What are the different characteristics of a rushed code?
• What is a sustainable code?
• What are the characteristics of a sustainable code?
• What are the benefits of a sustainable code?
• What is sustainability?
70
Value Results, not only Efforts – Work Efficiently, not Longer
URL:http://pm.97things.oreilly.com/wiki/index.php/Value_Results,_not_Only_Efforts%E2%80%94Work
_efficiently,_not_longer
Quote: “If you routinely insist that the programmers work long hours, be sure they are actually
producing additional, useable results.” -Venkat Subramaniam
• Productivity must be built on time, efficiency, and effort
Review:
Time and effort doesn’t equate into progress and productivity, especially in software projects.
Lines of code and work hours don’t mean that a developer has made progress or is productive.
The project manager should enforce balanced work ethic and work hours. Too much of
something is not good for the team. Longer work hours may exhaust the team resulting into below-
standard outputs; also, too much time may bring overcompensation in their part AND over complication
of codes.
In order to avoid the aforementioned scenarios, the project manager should implement a
workplace wherein results are valuable than the work hours spent on the development of the project.
By suggesting that they should only update him when progress is made, shall inculcate a result-oriented
mindset. As discussed in earlier chapters, workload should be broken down into small, manageable and
modulated tasks so that efficiency and effectiveness will be utilized.
71
• Results are much more important than speed, longer work hours.
• Longer work hours and large tasks will exhaust the developers.
• Small, manageable tasks are more beneficial than few large tasks.
• What are the effects of longer work hours to the developers?

• What are the risks that can be encountered from longer work hours?
• How can a project manager implement a results-based mindset?
72
Don’t Throw Spreadsheets at People Issues
URL: http://pm.97things.oreilly.com/wiki/index.php/Don%27t_throw_spreadsheets_at_people_issues
Quote: “In the end, software project management is about managing people and managing the
processes in which they are involved. Interpersonal conflicts within a team and between vying
organizational groups are very common. ” – Anupam Kundu
• Proper management of a list of tasks from a spreadsheet
Review:
Spreadsheets in software project management are merely, spreadsheets that contain tasks.
Spreadsheets must not be used to determine a task’s priority. It doesn’t even specify the resources,
timeframe, and importance.
Spreadsheets should NOT be used as an outline or a guide for the project. Expect the project to
break down and eventually fail. Conflicts will arise on the different tasks to be done. It may also result to
lack of deliverables that may annoy and infuriate the stakeholders.
This is not to say that spreadsheets are evil in a software project management, rather it is a
good place to start to clarify to the stakeholders the different information that the team will tackle.
Spreadsheets are good for monitoring the communication of tasks and its timeframe between the team
and the stakeholders.
• Spreadsheets must only contain a list of deliverables.

• The team should not solely rely on spreadsheets to track and monitor progress.
• Spreadsheets are a good medium of communication between the team and the stakeholders.
• What is a spreadsheet?
• What are the advantages and disadvantages of a spreadsheet in project management?
73
Build Teams to Run Marathons not Sprints
URL: http://pm.97things.oreilly.com/wiki/index.php/Build_teams_to_run_Marathons_not_Sprints
Quote: “To run a marathon, a team must be disciplined, practice everyday, and keep a sustainable pace.
When working on software projects, we don't want to run just once and exhaust ourselves. We need to
keep going at a steady pace. Sustainable teams are geared towards running marathons and not allowed
to just run sprints.” – Naresh Jain
• How to build teams that can sustain a “marathon”.

• How to build teams that don’t need micromanagement.
Review:
A team that can stand on its own, manage themselves and doesn’t require micromanagement is
considered as a sustainable team. By having this kind of team, the team members and the project
manager both benefit from the team’s independence.
A project manager is a facilitator of the team. Team members should co-exist with one another.
The project manager possess a special skill set that is different with his/her team members. In software
project management, a project manager may not be as skilled in coding compared to the teams
developers. Micromanagement is a head case for the project manager because he/she may not know
what a team member knows; therefore a sustainable team is ideal.
To form a sustainable team, it should be part of a team’s goal. Different trainings and team
building shall make the bond and understanding with one another, including the project manager,
stronger. Once a sustainable team is established, the project manager can now focus his other efforts to
different matters that concerns a project or the firm
74
• A sustainable team can stand on its own.

• A sustainable team doesn’t need micromanagement.
• Building a sustainable team should be part of the team’s goals.
• What is a sustainable team?

• What are the different benefits that can be received from a sustainable team?
• How can a project manager establish a sustainable team?
75
Go Ahead Throw that Practice Out
URL: http://pm.97things.oreilly.com/wiki/index.php/Go_ahead,_throw_that_practice_out
Quote: “A knowledgeable project manager should sift through all the possible activities a team might be
asked to do and retain only those that are vital to the success of this specific project. Once the leftover
practices from projects past are swept away, the team's productivity and throughput should get better in
a short period of time. ” – Naresh Jain
• How to identify the tasks that need to be stopped.
Review:
One of the project manager’s job is to carefully and identify the different tasks and processes
that the team is doing before it can cause a decrease in productivity from the team.
An overabundance of anything in the project is a good indicator that the team is having useless
processes and tasks. Some of these indicators include: the big pile up of documents in desks, new
members are being constantly added in the team, useless lines of codes, and glitches and bugs that keep
popping up during the testing of the software.
Before adding a process, it must be carefully analyzed. The project manager must ask himself
the following questions:
o What are the benefits to the team of the process?

o What can this process bring that can be detrimental to the progress and success of the
project?
o How effective and efficient will this process be?
The project should manager always be updated as to which processes are vital and which are
detrimental to the project and the team.
76
• Processes should be carefully analyzed before being added to the team.

• Overabundance of process slows down the project.
• Any process that is planned to be removed must be carefully examined.
• What are the indicators of a project or a team having useless processes?

• What are the effects of having too many useless processes?
• What are the criteria wherein removing a process should first be evaluated in?
77
You Get What You Ask For
URL: http://pm.97things.oreilly.com/wiki/index.php/You_get_what_you_ask_for
Quote: “Software teams suffer daily because their managers are tracking and measuring them against
the wrong parameters.” – Naresh Jain
• The right metrics of success are the keys to success,
Review:
Different companies use different metrics to measure just about anything. With these metrics,
team members are obliged to follow it and measure themselves with it. For example, if a company uses
the number of work hours as a metric to measure productivity, the employees would clock in more
hours without even being productive.
In order to really use the right metric for your team, make the metrics as part of the iterative
methodology. The project manager should conduct a meeting and discuss with the team the current
problems that they are currently facing. From there, the metrics of success can now be formulated. The
metrics should be unanimously be agreed upon. Metrics should be kept to a minimum of two or three,
so as not to create confusion.
The right metrics would definitely by a step forward to success.
• The metrics determine the kind of output for success.

• The metrics must be developed by the team.
• Metrics should be limited to two or three.
• How can metrics affect the success of the team?

• What are the steps to formulate the right metric for the team? How many should it be?
78
The Importance of the Project Scope Statement
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Importance_of_the_Project_Scope_Statement
Quote: “If the project plan is the heartbeat of a solid project management methodology, the scope
statement is the breath. The scope statement details the vision of the project. It describes the goals, the
deliverables, and documents what a successful conclusion to the project looks like.” –Kim Heldman
• The proper and effective utilization of a project scope statement.
Review:
The project scope statement explains the vision of the project. It clarifies the goals, deliverables,
and the documents to the successful conclusion of the project.
Ignoring the project scope statement right after signing-off is a bad idea as the team tends to be
misguided and lost. The scope statement outlines the tasks of every team member. Eventually when
they get lost, they might develop features that the stakeholders do no require, and are of the lowest
priority. The project scope statement is documented to keep everyone on track.
In some cases, the stakeholders tend to lose track as well. Once a deliverable is presented to the
stakeholders, they may deem it unsatisfactory and/or insufficient of the requirements they asked. The
signed copy of the project scope statement may be presented to remind them of the requirements that
were agreed upon.
Constant review of the project scope statement during meetings must be done. Project updates
are a good way to reflect on the progress that the project is undertaking.
Project scope statements are essential documents that outline the user requirements and
specifications. It is hard for the project to progress without the project scope statement.
79
• Project scope statements outline the goals, deliverables, and tasks to bring about the success of
the project.
• Losing track of the project is heightened when a project scope statement is not available.
• It may serve as a metric of the project’s success.
• What is a project scope statement?

• Why is the project scope statement important?
• What are the steps to document a project scope statement?
80
How Do You Define “Finished”
URL: http://pm.97things.oreilly.com/wiki/index.php/How_Do_You_Define_%22Finished%22%3F
Quote: “It is hard for a software development team to succeed if there isn’t a clear definition of what
success means. For developers, success entails delivering a product that meets the customer
expectations. However, to define total project success we need an accurate, shared definition among the
larger project team regarding what it means to “finish the project”.” – Brian Sam-Bodden
• How to declare a project finished.
Review:
Project success must be clearly defined at the start of the project life cycle. In an iterative
software development, it is “divide and conquer”. Tasks are divided, distributed among team members,
and be conquered.
At the macro level, code and its accompanying tests are more considered beyond. In the
waterfall model, tests are placed at the end of the project life cycle, wherein failure due to time
constraints in fixing errors that may pop up. Unlike, in an agile environment, bugs are fixed along the
project life cycle.
Software complexity is geometrically similar to its component interconnections. To simplify this

dilemma, design a demo environment, provide test scripts, and always accompany it with
documentation.
The underlying concept is that iteration is not only intended for software developers.
Coordination of tasks to the larger software project is a must. Business analysts, software project
managers must communicate all critical activities to the developers. And the communication of these
critical activities relies on the hands of the software project manager. By doing so, the concept of
finished will be clear and accepted by everyone.
81
• Software complexity is similar to the component interconnections in it.

• Iteration must be observed.
• What is software complexity?

• What are the different criteria to say that a project is finished?
82
Introduce a More Agile Communication System
URL: http://pm.97things.oreilly.com/wiki/index.php/Introduce_A_More_Agile_Communication_System
Quote: “Most retrospectives of failed projects place a great deal of blame on communication
breakdowns between software project managers, team members, and stakeholders. Project managers
are taught to mitigate communication breakdowns between team members, and provide constant,
effective communication. ” –Brian Sam-Bodden
• How agile communication minimize the content to noise ratio of meetings and status updates.
Review:
The project manager should establish the communication channels of the team early on the
project. Most project failures can be attributed to communication failure within the team.
To mitigate the risks of failure, a good communication methodology should be created. A short
15-minute meeting daily should be practiced instead of the long, boring meetings weekly, or every two
weeks. The short meeting must discuss three main agenda: what happened since the last stand-up
meeting, the tasks to be accomplished by the team members, and the discussion of any obstacle that
may surface in the succeeding days. This method is subjective, but is highly recommended especially in
an iterative environment.
Synchronous communication (physical presence) is not always more effective than

asynchronous communication (discussion boards). Such belief would prove a hindrance to implement an
agile environment.
Agile communication may seem troublesome, but it’s not. It shall prove to be a boon in the long
run.
83
• Communication breakdown is one of the causes of project failure.

• Project managers must establish the communication channels.
• Agile communication employs various procedures to extract status updates from within the
team.
• Why is communication breakdown attributed to project failure?

• What is agile communication?
• How effective is agile communication?
84
The Best People to Create the Estimates are the Ones Who Do the Work
URL:
http://pm.97things.oreilly.com/wiki/index.php/The_best_people_to_create_the_estimates_are_the_on
es_who_do_the_work
Quote: “Remember, the best estimators are those who will do the work.” –Joe Zenevitch
• How to execute proper estimates for the team.
Review:
At every start of a project, estimates need to be made. Allowing someone from outside to do
the estimates for the team is a terrible idea. This is because, that someone is not on par with the skill
level that exists in the team. There is a good chance that the outsider will commit incorrect estimates.
The project manager should also not make the estimates, because his skill level and specialties are
different from his team.
The wideband-delphi approach allows the developers to make the estimates with the business
analysts. First off, the business analyst will describe the project requirements. The developers will get a
chance to participate. They will also indicate some additional needs that would beneficial to both the
project and the team. The developers would write down their estimates on a card, and would be shown
to the business analysts. If the numbers aren’t far from each other, they will go to that estimate. If not, a
compromise would be agreed to.
This method is a great tool in such a way that the developers got the chance to voice out their
needs and provide a good estimate. A reason behind the numbers must be explained.
This kind of approach is good because it allows the developers involved in cost estimation. More
motivation shall be evident if followed.
85
• Estimates should not be done by either an outsider of a project manager.

• The developers must be given a chance to voice out his/her estimate.
• Wideband-delphi allows the users to participate in making the estimates for the team.
• What is a wideband-delphi?
• Why is it bad to ask someone from the outside to do the estimates?
• Why is it bad to let the project manager create the estimates?
• What are the factors that will improve your life.
86
Alice Doesn’t Live Here Anymore
URL: http://pm.97things.oreilly.com/wiki/index.php/Alice_Doesn%27t_Live_Here_Anymore
Quote: “We are fortunate to have the brilliant minds and insightful viewpoints of a virtual team. Be sure
to use this bounty respectfully. ” –Barbee Davis, M.A., PHR, PMP
• How to synchronize people from around the globe
Review:
As discussed in the previous chapters, a distributed team consists of team members that are
geographically scattered.
The following are some advices in dealing with team members across the globe.
o Be mindful of cultural holidays and the member’s culture in general. Set up meetings
and work hours patterned with their cultural upbringing.
o Accounting practices should be synchronized with all the payroll cycles of the team
members.
o Information traffic should be given importance.
o Respect the different standards that each country upholds.
o Technology in some other countries may not be up to date with the others. Be mindful
when dealing with a member with substandard equipments.
o The different time zones should be carefully considered when setting up a meeting.
Meetings must be comfortable for every team member.
• Team members will not always be working in the same geographic location with others. It is best
to consider the different aspects that come with it.
• What are the different things that are to be considered when working with members from
different locations across the world?
87
A Project is the Pursuit of a Solution
URL: http://pm.97things.oreilly.com/wiki/index.php/A_Project_Is_The_Pursuit_of_a_Solution
Quote: “The best way to conceptualize the end of a software project is to create a work breakdown
structure (WBS).” –Cynthia A. Berg, PhD (ABD), PMP
• How to create an effective Work Breakdown Structure (WBS).
Review:
The best way to start a project is by designing and creating a work breakdown structure (WBS).
The WBS gives an overview of the project as a whole, and is broken down into deliverables, and
deliverables divided into smaller work packages.
In creating a WBS, it is best to include the stakeholders and the team. The team is needed
because they are the ones that are most familiar with all the work to be done, plus as a bonus, they
would be motivated to do their jobs if they are involved in the formulation of the WBS.
After the WBS is created, the smaller work packages must be assigned to the team members or
groups of team members. These work packages may be assigned to different numerous milestones and
activities, as long as they are synchronized with the deliverables.
The WBS is a great tool to be used as an overview for the project at the macro level.
• WBS gives an overview of the project as a whole.

• Deliverables and work packages can still be broken down into activities and milestones to
increase productivity.
• WBS is a great tool for the team.
• What is a WBS?
• What are the steps in creating a WBS?
• What are the benefits of WBS?
88
True Success Comes With a Supporting Organization
URL:
http://pm.97things.oreilly.com/wiki/index.php/True_Sucess_Comes_With_A_Supporting_Organization
Quote: “If the organization is quick to “shoot the messenger”, team members will avoid sharing
troublesome issues and there may be an inclination to hide project problems.” – Cindy Berg, PhD (ABD),
PMP
• How to adapt to an organization’s culture.
Review:
Every organization has its own culture inside the workplace. A team working under a “quick to
shoot the messenger” environment tends to hide the problems and risks they encounter in the project.
And this kind of organization would produce projects that are substandard or failures. This is not healthy
to the team, employees, and the organization as a whole.
It is up to the project manager to inform the team about the potential risks and problems they
may encounter during the project life cycle. If a team is under a non-supportive organization, here are
some tips on how to complete the project:
o Ask, inquire, question until you understand the scope so that you are able to work
within it.
o Include team members and stakeholders in brainstorming, project planning, and project
execution.
o Be an honest software project manager. Be transparent about the problems to avoid
conflicts and uncomfortable discussions.
o Execute a desirable work environment within the project team that can be mirrored by
the organization.
o Participation in project updates and decisions from the team members must be fully
compulsory.
Project managers would definitely gain the confidence of the team, and the organization.
89
• Non-supportive organizations make their workforce hide their problems they encounter in the
project.
• Team members as well as the project manager should be given full support by the project
manager.
• Precautions must be observed when working in an oppressive environment.
• What are the qualities that define a non-supportive organization?

• What is the role of the project manager to his team in an oppressive organization?
• What are the precautions to be observed when working in a non-supportive organization?
90
A Project Depends on Teamwork
URL: http://pm.97things.oreilly.com/wiki/index.php/A_Project_Depends_on_Teamwork
Quote: “A Project is an endeavor of a multidisciplinary nature. It can be seen as a collective effort, jointly
performed by people of great diversity. ” – Lelio Varella, PMP
• How to instill team work within the project team.
Review:
A project is composed of two main things, activities and groups. Activities refer to the tasks that
are essential to the completion of the project, groups, on the other hand, are groups of individuals that
were carefully picked to complete a designated area of a project
To achieve project success, a smooth collaboration between the groups must exist. Activities
must be assigned to an individual in order to have a point of accountability. This individual may be the
leader of a specific group or a member of a group.
There are two principles that must be followed to encourage great teamwork between teams
and the individuals that belong to them. First is delegation. Delegation means, the transfer of tasks that
were assigned to one person to another. Delegation is very important, and the worthy person must be
selected. From there, the project manager needs to monitor the individual, but must not interfere.
The second principle is responsibility or “response-ability”. This must be carefully considered

when assigning delegation accepting assignments.
The project manager must establish leadership, delegation, and responsibility in the team. From
there, each of these ideals must support each other.
91
• Projects are comprised of: Activities and Groups.

• To encourage teamwork, two principles must be observed: delegation and responsibility.
• Delegation is the transfer of a task from one person to another.
• Responsibility is response-ability.
• What are the two main categories of a project?

• What are the principles to have teamwork in a team?
• What is delegation?
• What is responsibility?
92
Establish Project Management Governance
URL: http://pm.97things.oreilly.com/wiki/index.php/Establish_Project_Management_Governance
Quote: “Governance is a management method that is used to develop, communicate, implement, and
monitor polices, procedures, practices, and other acts used to run a project. Putting an effective project
governance structure and procedures into place helps ensure the project alignment, monitoring and
controlling of threats and opportunities, decision-making, and delivery of project packages which are
focused on the project planned.” – Ernani Marques da Silva, MBA, PMP, PgMP
• The value of project governance
Review:
Projects are comprised of individuals with different personalities, attitudes, and character.
Establishing project governance would make everyone work with chemistry.
Governance is a set of rules that are created and implemented in a project, or the organization
in general. When governance is established, monitoring of the project’s progress as well as identifying
potential risks is set.
To establish project governance, planning in advance should be done. Consider the following
variables in making project governance: goals, processes, structure, and external factors that may
provide hindrance to the completion of the project.
Organizations have different structures of authority. In some, project managers don’t have the
power to establish governance in a team. Even so, governance can be established if the project
management office has a project board.
A project board outlines the current governance that is working in an organization. It includes
approval of project plans as well as the changes made to it, inputs for progress reports, guidance on
risks and issues, and updates of the project progress.
93
• Governance is a tool to make a team, or an organization systematic and manageable.

• Project governance can only be established if the project manager has the proper authority to
do so.
• Project governance can not be established in a functional organization.
• What is Governance?
• What is Project Governance?
• What are the guidelines in making governance?
• What does the PMO outlines?
94
Do Not Fall Into the “Not Invented Here” Syndrome
URL:
http://pm.97things.oreilly.com/wiki/index.php/Do_not_fall_into_the_%22Not_Invented_Here%22_syn
drome
Quote: “Project management is nothing more than a set of processes, and when integrated and
combined they result in a methodology. And those processes/methodologies, have nearly unlimited
application.” – Dr. Paul Giammalvo, CDT, CCE, MScPM
• Processes associated with Project Management.
Review:
Project management is like a system, composed of different processes to accomplish a certain

task. The following are the processes associated with project management:
o Initiation – processes which distinguishes that a project exists.

o Planning – processes which enables the team what things that need to be done and how
to do them.
o Execution – actual implementation of the processes identified in the planning phase to
generate results.
o Monitoring and Controlling – processes wherein comparison of the project’s actual
progress to the plan.
o Closing – processes wherein the project is identified whether it is on time, within the
allocated budget, is in substantial conformance with requirements, specifications, and
the plan in general.
Software project management may be benchmarked with two leading jobs that “also uses”
project management: commercial piloting and medicine. In medicine and commercial piloting, there is
the near total authority by the people involved, both financial and professional. Both of these
professions, neither accept “average” practices, while in the IT industry, according to the PMI’s PMBok’s
Guide that the project management’s body of knowledge represents the skills, tools, and techniques
that are recognized as “good practices”.
95
Software project managers should think and look outside the box. This would bring them a
comparable success in their projects along with medicine and commercial piloting.
• Project management is comprised of different processes.

• There are five (5) processes associated with project management: Initiation, Planning,
Execution, Monitoring and Controlling, and Closing.
• Benchmarking the IT industry to the fields of medicine and commercial piloting is a good way to
observe and adapt the techniques that bring them a higher success than project management.
• What are the different processes associated with project management?

• What are the two best professions that the IT industry should be benchmarked with in order to
attain a higher rate of success?
96
PMO – Project Management Office, Effectiveness in Practice
URL: http://pm.97things.oreilly.com/wiki/index.php/PMO_-
_Project_Management_Office,_Effectiveness_In_Practice
Quote: “PMOs are intended to be centers of intelligence and coordination. They link strategic business
objectives to employees’ actions within departmental projects through unified portfolio management,
program management, and project management practices. ” – Angelo Valle
• The definition and functions of a Project Management Office (PMO)
Review:
Project Management Offices have become a trend and are being established in organizations
nowadays. A PMO is a group of people who supervise and support enterprise projects. PMOs exist to
standardize the process of handling projects.
There are three functions of the PMO, directive, supportive, and strategic. Directive in a sense
that they evaluate the processes that the teams do and they also define the guidelines of the project.
Strategic, when they set the priorities of the different project proposals for consideration. A supporting
role when they have a direct contact with the project management team.
PMOs may differ from each company that imposes them.
• PMOs have become a trend in recent organizations.

• PMOs can have any of the following functions: Directive, Supportive, Strategic
• PMOs vary in different companies.
• What is a PMO?
• What are the functions of a PMO?
97
Managing Human Factors in IT Project Management
URL:
http://pm.97things.oreilly.com/wiki/index.php/Managing_Human_Factors_In_IT_Project_Management
Quote: “People are human, so human emotions are natural in the workplace. But only people can
develop software. So, nurture and manage your human capital as carefully as you monitor and protect
your non-human resources. ” –James Graham, PMP
• The different human factors that can affect a project.
Review:
Software project management is defined by the abundance of numbers, dates, and lines of
codes. The human factor is the most often overlooked issue when a project is held back of its progress.
When humans are stressed, they usually revert to past actions that have been successful for
them. But, it won’t work in a software project. Projects constantly present iterations and challenges and
reverting back to the old practices would become a hindrance to the project’s progress. Flexibility and
adaptability is key to a software project’s success.
Stress must be minimal in a team for it to be efficient and productive.
• Human factors are commonly overlooked when there is a setback in a project.

• Human errors can be caused by stress.
• Stress allows an individual to revert back to its old practices that have become useful for them,
which is a problem in a software project management.
• What is the overlooked factor when there is a project setback?

• What is the human tendency when bombarded with stress?
98
The Value of Planning
URL: http://pm.97things.oreilly.com/wiki/index.php/The_value_of_Planning
Quote: “There will always be managers who advocate action over planning. Action is seductive, planning
is boring. ” – Derry Simmel, PMP, MBA, FLMI
• The importance of planning to a project.
Review:
More often than not, most project managers find planning to be boring and useless once they
are introduced to the realities of the project. According to them, action is more important than
planning, which is false.
Planning helps to guide the team on the trek of completing the project. It carries the value of
communication to the team.
There are two types of planning: Initial and ongoing.
Initial planning starts the pace and tone of the project. It also sets the direction of the project. It
views the project on the macro-level and helps the objective-setting for the project. The initial plan
should be created by the whole team. The risks and limitations must be well clarified to the team. Total
understanding of the project by the team will serve as the foundation of it.
On the other hand, ongoing planning is made whenever changes are made on the initial plan.
Plans change over the course of the project, thus, making it ongoing plan irrelevant. Don’t take it wrong
though, because the understanding of the project should be well-established and this kind of plan is
needed.
Plans have subtle value and must be considered carefully.
99
• Plans are often overlooked.

• Plans create a common understanding of the project that will serve as a foundation for the
project.
• There are two types of planning: Initial and ongoing.
• What is planning?
• Why is planning overlooked?
• What are the two types of planning?
• What is the value of planning to the project and the team?
100
Who is my customer?
URL: http://pm.97things.oreilly.com/wiki/index.php/Who_is_my_customer%3F
Quote: “You are the liaison to create a comprehensive status report which meets the needs of all
stakeholders. ” – Pavel Simsa, PMP
• The easy way of delivering status reports.
Review:
Status reports show the progress of the project, it also serves as gauge to the success and the
pace of the project. Some software developers ignore this value, which is important to both the project
managers and the company’s executives.
Here are some tips to make the software developers less-resistant to writing status reports.
o Make them understand the value of these reports to other team members as well as to
the other departments that are involved in the project.
o If a progress report is slow, evaluate if they were learning a new language or tool? Were
there unexpected risks and problems that showed up? Compile the report with the
explanatory report to justify the numbers.
o Give proper recognition.
o Create a group incentive.
The project manager is responsible to keep his team members always on the loop to help
update the project’s progress.
• Most software developers hate writing status reports.

• Methods can be formulated to inspire the software developers to deliver status reports.
• What is a status report?

• What are some ways to make the software developers write status reports?
101
Immortality of Scope Changes
URL: http://pm.97things.oreilly.com/wiki/index.php/Immortality_of_scope_changes
Quote: “Oddly enough, scope is one of the most flexible constraints.” – Pavel Simsa, PMP
• Proper management of changes in scope.
Review:
It is well-known in software project management especially in an iterative environment, change

is constant. There are three constraints to a project: cost, time, and scope. Scope is the most prone to
changes yet the most flexible constraint in a software project.
In cost constraints, it must be really kept at a constant value. As discussed in the previous
chapters, bringing in more developers will not be beneficial to the team; moreover, it will only bring
chaos and more time to update the communication channels. Time is a little flexible compared to cost;
technical debt may be incurred to provide a quick-fix.
Scope is a different thing though. Software projects also have their set of “wants” and “needs”
features dilemma. Generally, wants outnumber the needs. Want features are easier to develop and its
prioritization should be changed accordingly. Choosing which wants that are needed and are
dispensable must be identified at the start of the project.
• There are three major constraints in a software project management: Cost, Time, Scope.
• Scope undergoes more changes but is flexible enough.
• Generally, software possess the “nice to have” features rather than the “must have” features in
them.
• What is a constraint?
• What are the three major constraints in software project management?
• What must be prioritized more, the “nice to have” or the “must have” features?
102
Know Your Integration Points
URL: http://pm.97things.oreilly.com/wiki/index.php/Know_Your_Integration_Points
Quote: “Integration simply means linking together all of your various software programs so that all of
the subsystems work together to give you more functionality than you could gain from any one of the
applications on its own. ” – Monte Davis, MCSE
• How documented data flows help system upgrades.
Review:
Most organizations doing upgrades have assumptions that the effect of it will only to one
particular department or part of a system. A system is composed of different processes to achieve or
effectively complete a task.
Proper integration is installing an upgrade or introducing a new system while also documenting
the affected data flows and how will it also affect other systems. If an upgrade is integrated without the
proper documentation and analysis of data flows will result into chaos and confusion.
Document each system’s data flow of each system and the larger system in general to prevent
problems during integration.
• Integration is linking various processes or software so that the subsystems will increase its
functionality.
• Documentation of data flows for each subsystem and the larger system is a preventive measure
for any error that may arise during integration.
• What is integration?
• What are data flows?
• Why documentation of data flows is important?
103
A Word That Makes You Miss Your Deadline
URL: http://pm.97things.oreilly.com/wiki/index.php/A_word_that_makes_you_miss_your_deadline
Quote: “When you are developing a product that will be released in other languages than English, you
are adding numerous new risks and constraints to your project. ” – Pavel Simsa, PMP
• How language and the localization of software is overlooked.
Review:
Software has different language versions. Most often that not, after the English version is
released, succeeding versions of different language follow.
Translation and localization is never an easy task. Localization may last from a few days to few
months depending on its scale and complexity. Translation should be done properly. The translated
version should have the same functionality as the English version.
A snowball effect may occur when translation from English to a localized language occur. It is
always understood that an English version has already been released, and a change for localization may
affect the English version, especially if a translator is subcontracted from the outside.
To mitigate the snowball effect, strict criteria must be implemented and sequence the tasks
such that testing of the functionalities are separate from the English version.
• Localization of software is underestimated.

• A change in the English version may create a snowball effect of changes if not handled properly.
• What is localization?
• How long does localization take to be done?
• What are the causes of a snowball effect in localization of software?
104
Clear Terms, Long Friendship
URL:
Quote: “Really, all project artifacts are geared towards stating up-front the terms and goals the project
team setting out to accomplish. ” –Matteo Becchi, PMP
• How a definite set of rules, regulations, and standards make the project move smoothly.
Review:
Artifacts are an essential component of a project, and they are many of them. These artifacts,
especially the ones that were created during the early phase of the project help the team course its
direction. In creating the standards as well as standard procedures should be implemented. By doing so,
it helps the project run smooth.
Meetings are great opportunities to meet and communicate with the team members. During
meetings, issues encountered are shared; assigning tasks, status reports, etc. are the typical agenda.
Policies and regulations in a meeting should be set. There should be courtesy across the room.
Processes on making requests, approvals, and charging should be concise, clear must be made
by the third-party involved in the project.
• Artifacts should be concise and clear.

• Policies should be enforced in a meeting.
• Subcontractors must have a clear idea of the processes that involve them.
• What are artifacts?

• What can be considered as an artifact in a project?
• Why are policies need to be enforced in meetings?
105
Empowering Developers or a Story of Man Named Tim
URL:
http://pm.97things.oreilly.com/wiki/index.php/Empowering_Developers_or_a_story_of_a_man_named
_Tim
Quote: “You’ll be amazed what a good team can do with a clear vision, well-defined acceptance criteria,
and shared project priorities not determined by a lone software project manager but known,
documented, and managed by the entire team. ” –Ken Sipe
• Make the project engaging to the team.
Review:
Project managers should only manage and lead the team to the project success. The project
manager already has a lot of responsibilities. The project should be the team’s, not only as the project
manager’s or the stakeholder’s.
Team members should be empowered to give them a sense of entitlement and responsibility for
the success of the project. Team ownership of the project means that the members are involved all
throughout the project and a sufficient amount of lead by the project manager will steer them to project
success.
• Get the team members involved throughout the project life cycle.
• Less hands-on approach on developers will give them freedom and work on their best of the
abilities.
• How can team members be motivated?

• What style of management should the project manager should apply?
106
To Thine Own Self Be True
URL: http://pm.97things.oreilly.com/wiki/index.php/To_thine_own_self_be_true
Quote: “In order to manage or lead teams (and there are sharp differences), software project managers
need to be in complete control of themselves. They must have a strong understanding of their own
personal purpose, vision, mission, as well as personal and professional goals.” –Harry Tucker
• The importance of a project manager’s personal life.
Review:
Project managers are engaged into several projects. It is the task of the project manager to lead
the team to the eventual success of the project. A mentally-weak project manager could break down at
such an important task.
The personal life of professionals directly affects their mental health. For project managers to
empower and motivate the team, he/she first should be personally empowered. Signs of a project
manager’s mental-weakness are:
o He/she gets rattled very easily.

o Loses control of the project very easily.
o Gets discouraged when a critical problem affects the success of the project.
Initially, projects have unlimited potential and superior qualities but if managed by a project
manager who is mentally weak, the project could come breaking down faster than the blink of an eye.
Project managers should take time to find themselves and regain composure before dwelling and
focusing all his energy on a project.
107
• Initially, projects have unlimited potential. The decline of it may be caused by a mentally-weak
project manager.
• Project managers should be empowered themselves before being able to motivate and
empower his team.
• Projects start breaking down once the project manager starts to lose control.
• What are the attributes of promising projects?

• What can cause the failure of a project with unlimited potential?
• How important is the project manager’s personal life to the morale of the team?
• What are the good qualities of a project manager?
108
Make Money On Your Issues!
URL: http://pm.97things.oreilly.com/wiki/index.php/Make_Money_On_Your_Issues!
Quote: “When negotiating a contract with a vendor, specify that both vendor and your project team's
time be tracked against each separate issue that is encountered.” – Randy Loomis, PMP
• A good contract means good money.
Review:
Software even though has been release to the market is developed continuously. These updates
come regularly and some of them are costly. Most organizations depend on this kind of software, and
with good reason too. Purchased software may become outdated if not updated due to additional costs.
It is wise for the organization to create their own team to upgrade the software, with proper consent
from the original developers of course.
Upgrades are not without bugs or glitches. As the company further upgrades the software, more
flaws and glitches may surface. In order to “eliminate” the glitches, the software must be manually
debugged by the manufacturer and the team that were formed to upgrade it. This is additional cost and
time credited to the company.
To reduce costs there should be an agreement between the company and the vendor that the
bills will be based on situations not incurred. Money will be saved when the vendor is billed with the bug
fixes rather than the time it took to upgrade the software. This is a good criterion of a good contract.
109
• Software, even upgrading, are not without bugs.

• Software upgrades occur regularly.
• A team of developers from the vendor should be formed to perform manual debugging to
ensure a virtually clean software.
• A contract must be made stating that the bills would be based on the fixes rather than the time
it took to upgrade the software.
• What are software bugs?

• Are software upgrades bug free?
• What should be the contract state about the billing agreement to do a software upgrade?
110
Effective Manage the Deliverables
URL: http://pm.97things.oreilly.com/wiki/index.php/Effective_Manage_the_Deliverables
Quote: “Projects are comprised of a set of deliverables which, when completed, generate the completion
of the whole product, service or result. For software development projects, integrating all of components
will be crucial for the final result to work properly.” – Ernani Marques da Silva, MBA, PMP, PgMP
• Managing deliverables.
• Breaking down deliverables effectively.
Review:
A project is not considered a project without deliverables. These deliverables will be integrated
and be built as a whole to form the desired software.
The deliverables must be broken down into three stages: identify the deliverables, monitor and
control the deliverables, and manage the deliverables.
Identify the deliverables to outline the complete solution, the order of creation and
delivery, and the metrics to be used to monitor their development up until their
delivery, and be proactive in monitoring the progress against the metrics that was
chosen.
Monitor and control the deliverables involves the active observation of the broken
down work packets. These work packets, at certain point in the project, will be
compared against the metric that was defined in the previous phase.
Managing the deliverables is the integration of these work packets. Also, these packets
should undergo user-level acceptance testing. This phase shall identify the possible bugs
in the software.
The aforementioned approach may not be applicable to all software teams, but would prove
effective in minimizing the risks that may be encountered.
111
• Deliverables are a regular in a project.

• To manage deliverables, break it down into three phases: identifying the deliverables,
monitoring and controlling the deliverables, and managing the deliverables.
• Define metrics that the deliverable will be compared against.
• Break down the deliverables into work packets.
• Managing the deliverables is the actual integration and testing of work packets.
• What are deliverables?

• What are the three phases in managing deliverables?
• What are the tasks that involve the identification of deliverables?
• What are the tasks that involve the monitoring and controlling of the deliverables?
• What are the tasks that involve the managing of deliverables?
• Why should metrics be defined during the identification phase?
• What are work packets?
112
You Aren’t Special
URL: http://francisvictorcalo.pbworks.com/You-Aren%27t-Special
Quote: “Don't let your programmers reinvent the wheel.” – Jared Richardson
• Effective utilization of resources.
Review:
Excellent programmers and average programmers are obviously two different classifications of
programmers. These excellent programmers are expected to deliver software in the shortest possible
time with substantial and structured code, average programmers are the opposite. Sometimes these
excellent programmers develop too much big of a head and comes out as arrogant.
Arrogance is never good even though you can walk the talk. Programmers’ arrogance gave them
the self-entitlement of being “special” and above everyone else, even to the extent that they develop
their own programming language. While it is good to have excellent programmers on a team, their
arrogance might prove to be a hindrance to the project. Project delays may occur.
In order to mitigate this risk, project managers should be firm in instilling to everyone that they
are all equal regardless of their programming skills. If these arrogant programmers insist that they are
really good, impose a policy that the team will be using industry-standard tools.
• Excellent programmers can be arrogant.

• Their arrogance may lead them to develop their own tools in completing a task.
• The project manager should impose that industry-standard tools will be used.
• What’s the difference between an excellent programmer and an average one?

• What are the different ways to mitigate the arrogance of some programmers?
113
Share the Vision
URL: http://pm.97things.oreilly.com/wiki/index.php/Share_the_Vision
Quote: “Remember, your team, and everyone at your company, wants to succeed. Share your vision and
ask others to share theirs.” – Jared Richardson
• The importance of vision in the project.
Review:
When the vision isn’t shared to the team members by the project manager, they usually make
their own rationalizations and assumptions for the project. They may make contributions to the projects
which are meaningless or counter-productive.
The project manager should always explain the rationale of every task and the reason behind
doing it. In this way, the team members would be motivated and feel their importance to the project.
Information sharing is very vital to the chemistry and morale of the team.
A proper information sharing can be done by holding daily stand-up meetings need not to be
long and boring. Each member should give status reports on the task they are assigned to. In this way,
any potential risks or issues can be resolved. This method is way more effective than monthly meetings,
wherein the team members may be lost during the course of completion of a task assigned.
• Information must be shared to all team members to keep them from formulating their own
rationale on their assigned task or the project as a whole.
• Daily stand-up meetings are definitely better and effective than monthly meetings.
• When information and vision is shared across the team, morale and motivation tend to be high.
• Why is information sharing in the team vital?

• Why are daily stand-up meetings prove to be more effective than monthly meetings?
114
The Missing Link
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Missing_Link
Quote: “Those who participate successfully in large or small projects should be singled out for praise. As
they say in the agile world, this puts the “art of the possible” in proper perspective, aligning
organizational objectives with employee motivations. ” – Paul Waggoner, MBA, PMP, MCSP, CHP, CHSS
• Motivation as a tool for the team members to work on the project.
Review:
One of the most difficult tasks a project manager will encounter is making sure that all team
members are engaged in the details of the project, ahead of their assigned tasks. Team members are
occasionally confused between the different activities in a project.
Enter the SMEs or Subject Matter Experts. They are the individuals that possess a specialized
knowledge on a specific field. An SME selected to join would feel frustrated rather than honored. This is
due to the fact that they consider day-to-day operational tasks are more important than working in a
project.
In order to motivate these people, a proper coordination of the project manager to the
executives of the company must be made.
o All upper management executives should support the project.

o The job description should be changed from “perform tasks assigned” to “perform as a
team member as needed.”
o Project participation must be included in performance reviews by the Human Resource
department.
o A personalized letter of invitation from the stakeholders or executives of the
management be given to SMEs.
o Department head should clarify the importance of the project and the project’s value to
the organization.
These are just some of the ways to motivate SMEs who feel frustrated and or underperforming
in a project.
115
• SMEs or Subject Matter Experts are individuals with specialized knowledge of a specific field.
• Motivation of SMEs is important.
• Coordination with company heads to motivate these SMEs affect the members’ performance
and participation to the project.
• What are SMEs?

• What are the ways to motivate SMEs?
•
116
Estimate, Estimate, Estimate!
URL: http://pm.97things.oreilly.com/wiki/index.php/Estimate,_estimate,_estimate!
Quote: “ ..the best way to get better as estimating is to make sure you also keep track of actuals so that
the team gets feedback on how well they did in estimating.” –Richard Sheridan
• How to estimate “accurately”.
Review:
Estimates are generally done during the early phases of a project life cycle. These estimates are
also more accurate if the team members do it. Estimates are inaccurate but are useful, and everyone
can be better in estimating.
Constant reviews and revisions throughout the project life cycle is one way of getting better at
it. Variables should also be re-estimated since it constantly changes all throughout the project.
Estimates are valuable especially in the beginning if the project. It defines the budget, schedules,
scope and other important matters in a project. A team with good estimating skills shall have better
limits for future projects.
• Estimates are useful, especially in the early phases of the project.

• Estimates may include budget, initial schedules and scopes.
• Constant reviews and revisions can help team members get better in estimating.
• What are estimates?

• Why are estimates important to the project?
• How can it be developed further (estimating)?
117
Add Talents, not Skills, to Your Team
URL: http://pm.97things.oreilly.com/wiki/index.php/Add_talents,_not_skills,_to_your_team
Quote: “Hiring for talents, not for skills, is a radically different way to build a team. ” – Richard Sheridan
• Hiring talents to invest in them
Review:
The IT industry demands individuals with variety of skills to help a company grow and gain
competitive advantage over their competitors. Employers are attracted to applicants with a good set of
skills. Hiring them is not wrong, but it completely contradicts the principles in the IT industry. The
industry is a change and innovation waiting to happen.
Employers should hire applicants with the right set of talents instead of individuals with a long
list of skills. The talents these employers should look for are quite basic: good when working with teams
and interacting with people, and the enthusiasm to learn. Skills can be easily acquired over time, but
talents are innate abilities that are hard to replicate.
IT companies should invest in these talents.
• IT people already possess a good set of skills.

• IT is the vanguard of change and innovation.
• Veterans in the industry are more inclined to learning.
• Employers must invest in talents rather than skills.
• What are the things IT companies look for in an applicant?

• Why is talent more valuable than skill?
118
Increase Communication by Having Fewer Meetings
URL:
http://pm.97things.oreilly.com/wiki/index.php/Increase_Communication_by_Having_Fewer_Meetings
Quote: “If the meeting only happens when the boss or project manager shows up, kill it. Your team is
telling you they don’t get value out of it. Never hold meetings where only one person gets value. ” –
Richard Sheridan
• The value of having fewer meetings to increase communication.
Review:
Long, boring meetings are dreaded by the team members. A good indicator whether a meeting
is useful or not is when the project manager sets it up, skips it; if the members aren’t present, then
there’s something wrong with the methodologies you are using.
Stand-up meetings are more effective and more fun for the team. Casual meeting is also as
effective as stand-up meetings. Casually talk with a team member and ask him/her for a status report
wouldn’t take 10 minutes of her time. These short meetings hold value more than the long, dreaded,
monthly meetings.
*Refer to Share the Vision and Go Ahead Throw that Practice Out for more insights.
• Long meetings are of no value.

• Casual status updates take no more than five minutes.
• A stand-up meeting holds the same value compared to the long, monthly meetings.
• How can a meeting be considered useless?

• What’s a better way to get short but valuable status updates?
119
Teach the Process
URL: http://pm.97things.oreilly.com/wiki/index.php/Teach_the_Process
Quote: “For a process to be truly effective there must be a common understanding of the process among
all stakeholders.” –Richard Sheridan
• Empowerment of the stakeholders by teaching it to them.
Review:
Setting up a standardized process would make the project flow smoothly. And by teaching the
processes to the stakeholders, it makes everyone fall on the same page. This would give them a clear
idea how the project is being done, the risks that come with it, and also the potential problems that may
surface.
Gather the whole team, the project sponsors, some quality testers, and a few end-users and set
them up as a class. The lectures would focus on how the processes to be used in the project will affect
the deliverables. It also lessens the surprises when an unexpected problem goes off. By conducting this
class, the “students” may give useful inputs that may be utilized in the project.
• Standardized processes make the project run smoothly.

• Letting the stakeholders understand the processes is important.
• Setting up a class is a good way to converse the processes to the students.
• How do standardized processes make a project go flawlessly?

• What is the ideal method to teach the processes to stakeholders?
• Who are involved in the class?
120
IT Program Management – Shared Vision
URL: http://pm.97things.oreilly.com/wiki/index.php/IT_Program_Management:_Shared_Vision
Quote: “Once you have a common process and document/template tools, you are in position to
coordinate technical projects into programs.” – David Diaz Castillo, MBA, PMP
• Making the projects aligned into one program.
Review:
A common practice among organizations is to group the IT projects together under one program
to create business value in less time. All IT projects that are integrated under one program work for one
ultimate goal.
The project manager should align all projects and share it to the team. The business value of the
program should also be shared. To do the said alignments, here are some things to do to accomplish it:
o Find common points among the projects and extend its value from its mere stand-alone
importance.
o Risks, deliverables, and relationships should be defined between the projects of the
program.
o Keep the team members aligned with the solution that the program is trying to realize.
o Propose business solutions that are aligned with the projects and the program as a
whole.
The team should also standards to follow to have a smooth development of the program.
• IT projects are collected and built into one IT program.

• The IT program and the team should both be in the same page.
• Standards should be implemented to achieve smooth development of the program.
• What is the difference between an IT Project and an IT Program?
121
Buying Ready-Made Software
URL: http://pm.97things.oreilly.com/wiki/index.php/Buying_Ready-Made_Software
Quote: “...when the decision to buy ready-made software occurs in your company, spend more time
identifying the real need and researching the functional and technical details of the software chosen
before purchase.” – Ernani Marques da Silva, MBA, PMP, PgMP
• Reminders before purchasing ready-made software from a vendor.
Review:
Purchase of ready-made software saves a lot of time; this is why it’s common among
organizations. Installation of this software is not as easy as it seems though. There are several things to
be checked before considering a ready-made software. The software must be compatible and flexible
enough to mesh in with the organization’s legacy systems. Customization may be the solution in order
for the software to run flawless with the legacy systems, and in customization is where problems surface
and cause lots of troubles to both the vendor and the organization.
Below is a check-list that needs to be considered before installing a ready-made software to

your company:
o Company needs must be reviewed thoroughly.

o A due diligence report must be prepared when visiting the vendor.
o Prepare a vendor evaluation report, test case and plan.
o Ensure that the test case is completed and documented.
o Follow the test case and plan before signing a contract.
If everything from the above is conducted and tested, and all of them prove that the purchase of
the software is beneficial, then do it.
122
• Purchase of ready-made software is common among organizations.

• Ready-made software saves time.
• Ready-made software must be customized in order for it to work with the company’s legacy
systems.
• Installation of a ready-made software is not easy as it seems.
• Precautions should be considered when signing a contract with a vendor.
• What is ready-made software?

• Why is ready-made software popular among organizations?
• What are the risks that come with ready-made software?
• What are the things to be considered when purchasing ready-made software?
• What are the precaution to be considered when signing a contract with a vendor?
123
Document Your Process, Then Make Sure It is Followed
URL: http://francisvictorcalo.pbworks.com/Document-Your-Process,-Then-Make-Sure-it--is-Followed
Quote: “Document your process and make sure it is followed.” –Monte Davis, MCSE
• Process needs to documented and followed.
Review:
Documentation of processes is natural and an important part of project management.

Compliance and adherence to the process is of the essence.
Processes are documented not only for the fact that it must be followed (if not, it is useless), but
also it can be used for future projects by other teams; it also allows the users to review the processes; in
software, it may serve as reference for future maintenance and upgrades. Problems surface when the
people who formulated the process, stops following the process.
In software, it may result in data loss; in project management it may disrupt the work.
• Documentation of processes is very important.

• Documentation of processes is useless if no one adheres to it.
• It serves more than one purpose aside from the importance of following it.
• Why is documentation of processes important?

• What are the other purposes of documenting a process?
124
Don’t Always Be the Messenger
URL: http://pm.97things.oreilly.com/wiki/index.php/Don%27t_Always_Be_The_Messenger
Quote: “One of the most important roles of the software project manager (PM) is to facilitate an open
dialogue between the various members of the team.” –Martin Secoske
• Ways to avoid by a project manager to be a detriment to communication.
Review:
One of the tasks of a project manager is to define and establish the communication channels for
the team. Sufficient information must be delivered to the right person at the right time. Mishandling of
these communication channels may be a factor to a project’s failure.
The project manager usually handles the information and delivers it to the right person. If a
project manager has a non-technical background, information may be passed inaccurately.
There are many methods on how to properly handle the information passed through the
communication channels. One way is to use a wiki (See Chapter Use a Wiki), or the daily stand-up
meetings (as discussed on Chapter Increase Communication by Having Fewer Meetings).
Communication is vital in a project management, and its delivery is in the utmost importance.
• The project manager must define and establish the communication channels for the team.
• Problems may occur if the project manager with a non-technical background is asked to deliver
technical information.
• There are a lots of tools that can be used for proper and accurate communication.
• What is one the project manager’s task regarding communication?

• How frequent should information be passed?
• What are ways to avoid mishandling of communication?
125
Planning for Reality
URL: http://pm.97things.oreilly.com/wiki/index.php/Planning_for_Reality
Quote: “The pace of development will naturally vary throughout the life of the project.” – Craig Letavec,
PMP, PgMP, MSP
• Creating a schedule with risks taken into account.
Review:
Software projects are known for its schedule and its deliverables. It is also infamous for being
behind schedule and producing substandard deliverables. Poor scheduling is one of the main reasons for
this outcome.
In an agile environment, estimates, project scope, and plans continuously change throughout
the project life cycle. Technical debts and the constant changes may make a project behind of schedule.
To mitigate this issue, a buffer must be created and added to the estimated schedule. Simply
add 10% to the number of days per work packet or package. This is 10% buffer is called as such because
obstacles and hindrances typically arise over the course of the project. It may not look good, but it shall
pay off in the long run. To be able to really maximize these buffers, allot more buffers to high priority
work packages, and less with the low priority work packages.
This technique can help the project stay on track and on time for its delivery.
• Software projects are infamous for being behind schedule.

• Software failure may stem from poor schedule estimates.
• Adding buffers to the schedule would help the team to work on any obstacles that are met
along the way.
• What are buffers?

• What is a smarter way to allocate buffers to the schedule?
126
Avoiding Contract Disputes
URL: http://pm.97things.oreilly.com/wiki/index.php/Avoiding_Contract_Disputes
Quote: “The best way to avoid possible conflicts is to be fair when negotiating the contract.” – Jorge
Gelabert, PMP
• The nature of contract disputes.
Review:
Project managers know what type of contract to use that not only depends on the products and
services to be purchased, but also includes the risk level that the he and the vendor are willing to
presuppose.
Contract disputes surface when there are disagreements during negation (or renegotiation) of
the project. It may involve the financial aspects or the risk aspects of the project.
Well-defined user requirements provide lesser contract disputes, but the problem is, perfect
user-requirements are very rare. Even so, conflicts may arise throughout the project.
To mitigate the chances of getting disputes with a client, it is best to treat them as business
partners rather than antagonists. It shall help in the negotiations, wherein both parties will benefit from
each other. Presenting a fair contract, will create a good relationship between the company and the
client and will help avoid any conflicts. A fair contract focuses not only on the company’s best interest
but also to the general success of the project.
When a contract disputes arise, legal actions should be considered as the last option. Time and
the costs would only be detrimental to both parties. Therefore, contracts should be renegotiated if
there a party feels that a dispute will surface.
127
• Project managers know what contract to use.

• Contract disputes are disagreements in negotiations.
• A contract outlines the financial aspects and the user requirements for the project.
• Treating clients as business partners would be beneficial to both parties.
• Legal action should be the last resort in the event a contract dispute arises.
• What is a contract?
• What is a contract dispute?
• When do these contract disputes arise?
• How should be the clients be treated as?
• What should be the last resort in the event of a contract dispute?
128
Project Sponsors – The Good, the Bad, and the Ugly
URL: http://pm.97things.oreilly.com/wiki/index.php/Project_Sponsors_-
_The_Good,_the_Bad,_and_the_Ugly
Quote: “Every project needs a sponsor. Usually the person who initiated the project and is responsible for
providing the financial resources to successfully complete the project.” – Jorge Gelabert
• The different types of sponsors.
Review:
Project sponsors are the ones who “provide the resources” needed by the project. They can be
both an invaluable asset and an obstacle.
There are typically three types of sponsors: “the good”, “the bad”, and “the ugly”.
o The Ugly – these kinds of sponsors are usually assigned and are often replaced so there
is really no continuity. This kind of sponsor does not listen to the project manager and
solely focuses on the arbitrary dates given by the ones who assigned him/her to the
project. One way of dealing with them is responding positively to his/her desires or
another way is to find a surrogate sponsor.
o The Bad – these sponsors may provide to be a hindrance to the project. They may
interact directly with the team members, make inappropriate decisions; “replacing” the
project manager and bring confusion to the team. Dealing with them defined specific
job description may change their behavior.
o The Good – they understand their role to the project and behave accordingly.
Whatever the type of sponsor a project may have, it is the task of the project manager to
manage them with the same manner they manage the project.
129
• Sponsors facilitate the resources that the team needs.

• Sponsors may be categorized into: “good”, “bad”, and “ugly”?
• Good sponsors know their role.
• Bad sponsors are intrusive.
• Ugly sponsors are there just for the sake it.
• What are sponsors?

• What are the types of sponsors?
• What are the ways to deal with each sponsor?
130
Not Superheroes
URL: http://pm.97things.oreilly.com/wiki/index.php/Not_superheroes
Quote: “Make sure that you have teammates with complimentary skills work in partnership with you in
areas where your weaknesses lie. ” – Angyne J. Schock-Smith, PMP
• Identification of strengths and weaknesses.

• Working with your strengths not weaknesses.
Review:
Project managers are tasked to do a lot. Their main tasks are interacting with people, leading
and motivating the team, and constantly update the progress of the project.
As a project manager, one should possess many strengths but it is impossible to have all the
strengths, because as we all know he/she is still a human being, imperfect. Evaluating the strengths and
weaknesses of a project manager is a must. After it is done, the team members should be evaluated
next.
After all the team members’ strengths and weaknesses have been assessed, it is now time for
them to be paired with members with complimentary attributes. In this manner, the team, as a whole,
will be created without any glaring weakness.
• A project manager should know his strengths and weaknesses.

• The team members should also be evaluated for their strengths and weaknesses.
• The team should then be comprised of members that compliment each other.
• What should be done to be a more effective project manager?

• How should be the team be configured after evaluating their strengths and weaknesses?
131
How to Spot a Good IT Developer
URL: http://pm.97things.oreilly.com/wiki/index.php/How_To_Spot_A_Good_IT_Developer
Quote: “No matter how personable and skilled your applicant, always verify credentials with the issuing
institutions and check out resume entries with the former employers. Careful hiring practices may
prevent a multitude of future problems.” –James Graham, PMP
• How to select and add a team member.
Review:
A lot of factors must be considered when hiring a potential team member. Skills, work ethic, and
attitude are just some of the criteria that the applicant is tested against.
Consulting with the developers should be done first. Discuss whether skills and experience is a
big plus; also discuss which technical knowledge is mandatory. Test the applicant’s skills during the
interview; have him take a test developed by the team’s developers. Identify whether his/her coding
style would fit in with the team. The tests given should also assess the applicant’s ability to explain in
technical and layman’s terms.
Work ethic is also a big factor that has to be considered carefully. Evaluate his skill in interacting
with different people. His attitude and character should also be looked into.
The addition of a new member to the team could make or break the current team, therefore, it
must be carefully analyzed and evaluated.
• There are many factors that must be considered when adding a new team member.
• Assess the applicant’s knowledge, skill, and work ethic.
• Coordinate with the developers to create a series of tests for the applicant.
• What are the different factors to be considered when a hiring an applicant?

• What can be done to assess the applicant’s skill and knowledge?
132
Communicating is Key
URL: http://pm.97things.oreilly.com/wiki/index.php/Communicating_Is_Key
Quote: “The person may have many different certifications and a list of titles and accreditations after
his/her name, but without the basic knowledge of how to collaborate with others, the work of the project
cannot be accomplished properly. ” – Gennady Mironov, CPM
• The importance of meeting people.
Review:
Most of the project manager’s time in a project is spent dealing with people. That’s why it is
important that a project manager must have good people skills. And a project manager with an
exceptional communication skill would do wonders for the project.
In a non-distributed project it is imperative that the project manager hold a big meeting at the
very beginning of the project. The meeting must be attended by the stakeholders, sponsors, and of
course the team members.
A physical communication demands immediate response and a discussion or a conversation

must take place. While in a non-physical communication, examples are phone calls, emails, etc., there is
that lack of urgency to converse with the one at the other side of the line.
A personal meeting implies that the project manager is as serious as he can gets and can
motivate the contact person on the project.
• Project managers spend a lot of time interacting with people.

• It is imperative for the project manager to hold a meeting at the very start of the project.
• Physical or personal meetings mean more than non-physical conversations.
• Where do project managers spend most of the time in a project?

• What does a personal meeting with a client imply?
133
RESTful Architecture Makes Project Management Extremely Simple
URL:
http://pm.97things.oreilly.com/wiki/index.php/RESTful_Architecture_Makes_Project_Management_Ext
remely_Simple
Quote: “Once you know what the customer wants and you know what resources are already available
with your organization that must be taken into account, NOW you can choose your best weapon to fight
the problem.” –Krishna Kadali, M. Tech
• Analyzing the user requirements
Review:
During the first meeting with a client, it is best to find out the tools and resources that the
company possesses. From there, defining the user requirements would be easier. And as we all know,
the user requirements dictates the outcome of a project. This would also give a clearer idea on what
means are to be used. Lastly, by knowing the company’s resources, it would be easier to formulate the
integration process of the software to the company’s legacy systems. (See Know Your Integration Points)
As soon as the team starts the development phase, it is best to fulfill first the user requirements,
and then when there is enough time to add the “nice to haves”, do it.
Software exists to solve different business problems.
• Focus first on the current resources of the client’s company.

• When the resources are identified, integration points must be defined as well as the user
requirements.
• The user requirements should be first completed during the development phase, the “nice to
haves” can come later.
• Software projects exist to solve business problems.
134
• What should be known first on the first meeting with the client?
• What is the importance of knowing the client’s resources?
• What should be completed first during the development phase of the project?
• Where do software projects revolve?
135
Keep Your Perspective
URL: http://pm.97things.oreilly.com/wiki/index.php/Keep_Your_Perspective
Quote: “Perspective means looking for the best solution, not the fix that feels right to the users.” – James
Graham, PMP
• Being objective not subjective to user demands
Review:
End-users tend to be frustrated with the current system they use. And as a project manager,
listening to their complaints is part of the job. The project manager should ask questions as to why,
when, and how do these problems occur. This is to find the root cause of the problem. Prevention is the
best way to fix these problems, not curing the symptoms.
As humans, it is natural for us to sympathize whenever a fellow human being is troubled. This is
also the case in project management. Project managers tend to get carried away with the problems that
these users complain about thus, focusing only on the quick-fix of the problems, instead of really digging
deep down to remove the root problem.
Being objective must be maintained at all times. Let the users complain all they want, and then
solve the root cause of their complaints.
• Customers are never really satisfied.

• Project managers often overlook the asking part when users voice out their problems on the
system.
• Providing a quick-fix to the symptoms won’t cure the disease.
• Be object all the time.
• What is the common mistake that project managers do when end-users complain?
• What should be done to fix the problems of the system?
136
Keep It Simple Simon
URL: http://pm.97things.oreilly.com/wiki/index.php/Keep_Your_Perspective
Quote: “The team members of the project must have the ability to completely visualize the objectives of
the project and complete actual work. ” – Krishna Kadali, M. Tech
• Keeping it simple is the best way.
Review:
There are main steps to avoid a complex solution to a simple problem.
The first one is, keep the requirements simple. Clients and users tend to exaggerate what they
want or encountered. The key is to ask questions in order to arrive at a simpler idea that summarizes all
the complex wants of the client. Have a business analyst translate it into diagrams in order to arrive at
the root cause. As discussed in the previous chapter Favor the Simple over the Complex, a complex
software may be caused by analysts doing a horrible translation. The requirements must be clear,
simple, and identified, development phase shall commence.
The second one is, develop iteratively (See The Fallacy of Perfect Knowledge). The idea is to
develop the software in smaller work packets by focusing on the key features first, and then present it
to the client. This is crucial in assessing the progress made by the project.
• Software requirements from customers are presented in complex form.

• User requirements must be simplified, clarified, and identified before the development phase
commences.
• Business analysts translate the complexities into simpler format.
• Iterative development is ideal.
• What must be done first before development can begin?

• What is the ideal methodology in developing software?
137
The Holy Grail of Project Management
URL: http://pm.97things.oreilly.com/wiki/index.php/The_Holy_Grail_of_Project_Management
Quote: “The challenge for the project manager (PM), especially when working with a new team, is to
convey the essence of project management in a 30 minute overview, without overwhelming the team
with methodology details.” – Paul Waggoner, MBA, PMP, MCSE, CHP, CHSS
• Convey the concepts of project management to the team.
Review:
Briefing of new teams assigned to project management should be introduced to its concepts.
Such briefing should not take more than thirty (30) minutes. The most important concept must is
presented as the “holy trinity” of the project. A triangle represents this notion. In the vertices are: time,
cost, and scope; and in the center is quality. One adjustment to any vertex will greatly affect the center
area of the triangle, which is quality.
Some key concepts that should be conveyed:
o Each member’s weight and importance is vital to the team.

o Define project risks and how to get rid of them.
o Tasks that require breakdown.
o Assigned tasks with corresponding completion schedule.
o Potential delays and obstacles in schedule.
o Communication channels’ plans and strategies.
• The “holy trinity” of project management is composed of: time, scope, and cost; with quality at
the center of it.
• Project management concepts should be conveyed in a simple and brief manner.
• What is the holy trinity of project management?

• How should project management concepts be conveyed to new teams?
138
Meetings Don’t Write Codes
URL: http://pm.97things.oreilly.com/wiki/index.php/Meetings_don%27t_write_code.
Quote: “… evaluate your own practices and see if you can improve them on your own.” – William J. Mills
• Proper facilitation of a meeting.
Review:
Meetings are dreaded by project teams, especially software project teams. They are made to
suffer in a long, boring, chit-chat that sometimes proves to be useless. Therefore, meetings should hold
value and is relevant to everyone in attendance.
Meetings should have an important purpose as the centerpiece of it. All people in the meeting
must be relevant and has a purpose to the agenda that will be discussed. Personal chats, off-topic
resolutions should be saved after the main agenda have been discussed. It must also be understood,
that only problems are to be discussed in a meeting, not solutions. Solutions must be discussed by
smaller groups after the meeting. Time must be carefully observed. Time must be proportional to the
complexity of the matters to be discussed in the meeting. Big, long-winded meetings are useless, stand-
up meetings are more effective.
• Meetings are dreaded by software project teams.

• A specific purpose must be the centerpiece of a meeting.
• Problems are the only one to be discussed in a meeting, not solutions.
• Stand-up meetings are more effective than big, long-winded ones.
• What must be the centerpiece of a meeting?

• What are to be discussed during the meeting? After the meeting?
• What are some guidelines to hold an effective meeting?
139
Provide Regular Time to Focus
URL: http://francisvictorcalo.pbworks.com/Provide-Regular-Time-to-Focus
Quote: “Typically, a person takes about 20 minutes to regain their train of thought after one of these
interruptions. A five-minute question actually costs 25 minutes and a quick 10-minute meeting actually
costs 30 minutes of potential work. ” – James Leigh
• The value of focus.
Review:
Distraction must be minimized at best to avoid the loss of focus, especially from developers.
Developers possess busy minds all the time. And if interrupted, it requires them a minimum of 20
minutes to regain their train of thought.
It would be best to allot time that allows developers to focus on their work, with minimal to zero
distractions. Two hours of uninterrupted work or whole days with no interruptions would raise their
productivity to a whole another level.
Infomania, refers to information overload. This is a common ingredient for distractions to

developers. Developers’ minds are clockwork of formulating logic, codes, structure, and different
variables that a slight distraction would swap the new information to what’s currently inside. Their train
of thoughts is very fragile.
• Software developers’ minds are busy 24/7.

• Any dorm of distraction can easily disrupt their train of thought.
• Infomania refers to information overload.
• Uninterrupted time should be allotted for developers to increase their productivity.
• What is infomania?
• What should be allotted to increase the developers’ productivity?
140
Work in Cycles
URL: http://pm.97things.oreilly.com/wiki/index.php/Work_in_Cycles
Quote: “The most effective software projects are created in environments that ensure developers are
mentally productive.” – James Leigh
• Maintain high productivity.
Review:
Human body work in cycles and productivity is of no difference. Too much work may cause
stress, which in turn would decrease productivity and work quality. A worker must take breaks every
now and then to recharge.
Software development is no different; all team members are under stress especially the
developers. Having the best work environment would increase their productivity. Iterative development
has four main phases (planning, action, completion, reward), works in cycles.
Planning refers to the preparation for action. It answers the 5Ws and the 1H (What, When,
Where, What, Why, and How). Action is implementing the plan. Completion includes quality control.
Reward is acknowledging the team for its effort.
It is the project manager’s job to keep the team ready, in line, and motivated to do the work.
• Human bodies work in cycles and it directly affects their productivity.

• Establishing a good work environment increases the team’s productivity.
• Iterative development has four main phases.
• What are the main phases in iterative development?

• What is the best way to increase the productivity in the work place?
• What happens when a person works too much?
141
Responding to a Crisis
URL: http://pm.97things.oreilly.com/wiki/index.php/Responding_to_a_Crisis
Quote: “Establishing clear responsibilities for dealing with crises is a good start.” – James Graham, PMP
• Preparation and readiness to any problem.
Review:
Software projects are prone to risks. Even implementation of highly preventive measures,
although risks will be minimized, they will still be encountered.
Each team should include risk management in their plans. Here are some tasks that need to be
done in order to be ready for any problem that may occur during the course of the project:
o Team briefings should be held regularly to discuss unexpected risks. These meetings
should be done more frequently as the critical phases of the project draws near.
o Any risk that is identified and foreseen should have a corresponding course of action.
o All team members should be train to handle these risks.
o A crisis management plan should be created and it should have a clear method of
communication
Crises can be avoided, but if one does occur, the team should be prepared and ready to resolve
any risk or problem it may present.
• Software projects are prone to risks.

• There should be a checklist of tasks that need to be done in a case a crisis or risk present itself.
• All team members must be equipped to handle risks and problems.
• What should be done to prevent risks and crises?

• What is a crisis management plan?
• What does a crisis management plan specify?
142
What Do They Want to Hear Anyway?
URL: http://pm.97things.oreilly.com/wiki/index.php/What_Do_They_Want_to_Hear,_Anyway%3F
Quote: “The hardest, yet the most common way to convey software project information from one person
to the next is a formal presentation.” –Martha Legare, MBA, PMP
• How to prepare for a formal presentation.
Review:
The general idea of presentations is that is too long, and is boring. But presentations are
important in communicating the project ideas to the team and to the company executives who will
approve it.
A presentation must be straight to the point, but must contain enough visuals to keep the
audience entertained or focused. Visuals help the speaker convey his ideas without the use of words.
Careful preparation must be done because the speaker is actually the one who sells his ideas not the
PowerPoint presentation.
A PowerPoint presentation must not be text-heavy, otherwise it conveys a boring message to

the audience. And if this happen, they will lose focus and interest in your presentation. The speaker
must also prepare the PowerPoint’s central point and relevance to the audience. The presentation
should be presented in not more than five minutes (5).
A good presentation is comprised of a good speaker and relevant and good presentation. Both
of which can be prepared for in advance.
• Presentations are used to convey ideas to executives that have the power to approve a project.
• The presentation must not be text-heavy.
• The presentation should not take more than five minutes to be presented.
• Why are presentations important?

• How long should a presentation be presented?
143
Make Project Sponsors Write Their Own Requirements
URL:
http://pm.97things.oreilly.com/wiki/index.php/Make_Project_Sponsors_Write_Their_Own_Requireme
nts
Quote: “A failed software project hurts the project owners most, since they have put up the money to
fund the project and were expecting to use the software to earn back their investment.” – Miyoko
Takeya, PMP
• Make the project owners write their own requirements.
Review:
IT projects in America and Japan has a failure rate of 75% which is quite staggering. This is the
reason why software projects have been categorized in an improbable success rate. Reasons behind
these failures are poorly defined user requirements.
Definition of requirements is done during the early stages of the project with the project owners
or sponsors. It is then translated by the business analysts which then will be passed on to the
developers. If a project fails to define its requirements from the very beginning, then it is very likely that
the project will fail.
To resolve this dilemma, project owners must be fully participative during the definition of
requirements. Their misconception however, is that they can not be involved since they are not tech-
savvy. Project owners are the ones that know what their software will look like.
The project manager should now proceed to gathering the company’s current resources, the
time constraints, and the skill set as well as the holy trinity of project management which are all
required in the project’s success. The more accurate the requirements are, the higher rate of success is
present in the project.
The project owners are the ones who will provide the funds and resources needed for the
project which also makes them the ones with higher stakes placed on the project. Therefore, it is a must
that they have a close relationship with the team.
144
• Leading countries such as USA and Japan have low software projects success rate.
• Project failures are often attributed to poor requirement definition.
• Project owners should be proactive in the project especially during the identification of
requirements.
• The requirements are critical components to the project’s success.
• Which countries have a low success rate for IT Projects?

• What are the main causes of these failed IT projects?
• Who should be most involved in identifying the requirements for the project?
145
One Deliverable, One Person
URL: http://pm.97things.oreilly.com/wiki/index.php/One_Deliverable,_One_Person
Quote: “Every deliverable should have a single person who is responsible for its completion. Everyone
working on the project should clearly understand who is responsible for the delivery of each item.” –Alan
Greenblatt
• Proper handling of accountability.
Review:
In situations where failure rate is high, people tend to be allergic to responsibility. And of
course, when the success rate is high, people would jump on the bandwagon faster than Pacman’s
punches. The misconception of blame and accountability is based upon the aforementioned scenario.
Accountability simply refers to a person tasked in handling a task and being responsible for it.
Nevertheless, accountability is taken the wrong way. When something fails, people will point the blame
and hold that person accountable.
Accountability works through responsibility. A member accountable on a task should be expert

on the task as well. If a problem arises on that task, the person will answer all the questions pertaining
to that task, and he/she will also be the one to coordinate with the project manager about the issues
concerning the task.
Accountability must not be associated with blame, rather with responsibility.
• Accountability is perceived as something that is negative.

• Accountability is assuming responsibility.
• What are the misconceptions with accountability?

• What is the real definition about accountability?
• What are the responsibilities that come along with accountability?
146
Requirement Specifications – an Oxymoron
URL: http://pm.97things.oreilly.com/wiki/index.php/Requirement_Specifications_-_an_Oxymoron
Quote: “Keep the what you are trying to build separate from the how to build it.” – Alan Greenblatt
• The differences between specifications, requirements, and features.
Review:
Specifications refer on how problems will be solved. Requirements refer on how the features
are going to tackle and resolve a problem. Features are the solutions that will solve the problem defined
by the requirements.
Requirements, features, and specifications go along with problem, solution and method. The
differences in these terms are important as to how and who will work on them. The project manager is
never concerned to address the requirements, it is the business analyst’s job to do. Features concern
the developers. Specifications on the other hand are the things the project manager must be involved in.
Proper realization of the meaning of these terms is important as to not bring confusion to the
team.
• Requirements, features, specifications work with problem, solution, method.

• The project manager must not be concerned with the addressing of the requirements, the
business analyst is.
• Features concern the developers.
• The project manager should be the one to address the specifications.
• What’s a good analogy for requirements, features, specifications?

• Whose task is it to address the requirements?
• Whose task is it to address the features?
• Whose task is it to address the specifications?
147
Speed is Life: More is Better
URL: http://pm.97things.oreilly.com/wiki/index.php/Speed_is_Life:_More_is_Better
Quote: “Scientific studies, however, prove the advantage of optimal, rather than excessive, speed for
specific moves, tactics, and delivery profiles. Optimal speed, not maximum speed is the goal.” – Matt
“Boom” Daniel
• How to determine the use of speed in a project.
Review:
In the present IT industry, speed is not considered to be the ingredient for success. Focusing on
speed, more often than not, produces a substandard quality of software wherein codes are
unstructured and difficult to read for future upgrade and maintenance. If it’s just speed with little to no
marketing, then it will never catch up in the fast-paced IT industry. Identifying when to use and how to
use speed is very important in a project.
• Speed doesn’t guarantee a project’s success.

• Focus on speed will generate software with substandard quality.
• What is speed in the IT industry?

• Can speed be considered as a determinant for a project’s success?
148
The 2-Day Rule
URL: http://pm.97things.oreilly.com/wiki/index.php/The_2-Day_Rule
Quote: “The customer defines "done", not a status report.” – Udi Dahan
• Actual progress vs. Work done
Review:
In a waterfall model-based project, they heavily rely on the status updates given out by team
leaders. The testing also comes in the later part of the project, which gives the team a blind spot
whether or not the project will be accepted and used by the intended end-users.
Status reports and actually progress are often interchanged. Actual progress refers on how
much of the project can already be used. Status reports on the other hand refer to the amount of work
done by the team members. For example, a project that is 95% done isn’t necessarily mean that it’s
usable and good to go.
When users begin their tests on a 95% completed project, they will surely be disappointed by
the amount of bugs they will encounter and lack of usability it presents at this rate. The users may doubt
the success of this project once it hits 100%.
Iterative development is strongly suggested to avoid these risks.
• Work done does not equate to progress.

• Status reports gives information about the total work done.
• Progress refers to the usability of the software.
• What is a status report?

• What is actual progress?
• What are the differences between the two?
149
Scrolling Through Time
URL: http://pm.97things.oreilly.com/wiki/index.php/Scrolling_Through_Time
Quote: “By recognizing the importance of nose-to-nose interfaces between the developer and the real
customer, we have evolved to collectively creating User Stories, and prioritizing features based on the
business value they will provide to the customer, rather than requirements lists.” – Kim MacCormack
• The value of interacting with the client.
Review:
Constant interfacing with the client is crucial to the project. Without doing so, it may create
problems, and may be used against the team. A team that fails to meet with its client would have to
heavily rely on their assumptions and guesses of what the user requirements really dictate.
At the end of the project, when the given requirements have not been due to the team’s
reliance on assumptions, it can be used as a weapon against them. The client can deem that the present
project does not meet the specified user requirements, thus, no payments shall be made. This would
result into an utter waste of time and effort. Plus, the company’s reputation for getting things done
would take a big hit.
In cases like this, the assumptions must be relayed to the customer, via a middle-man. As
thoroughly discussed in this book, specific details of the user requirements are essential to a project’s
success.
• Requirements if not met can be used as a leverage against the team.

• Assumptions must be well-documented and be agreed upon by the customer.
• Project success heavily relies to the fulfillment of the user requirements.
• How can be user requirements be used as a leverage against the team?

• What can be done wherein the customer has the inability to physically interface with the team?
150
How to Kill Morale
URL: http://pm.97things.oreilly.com/wiki/index.php/How_To_Kill_Morale
Quote: “Morale is one of those things you know you need, but it is hard to grow and measure. ” –David
Bock
• The importance of morale.
Review:
Morale can be used as a good indicator and measure on how much the team is confident is with
their leader, and how much they are willing to give out for the sake of the project. Also, morale is a good
indicator of team productivity; a team with high morale gives a high productivity rate.
Controlling morale is an abstract thing; it comes out naturally from the individual. The project
manager being the head of the team must possess a high morale with high productivity. This shall be
picked out and mirrored by the team. On the contrary, poor leadership will kill morale. A project
manager with little to no confidence would lose his team fast. And this will create a snowball effect that
can cripple the whole team.
Good leadership and confidence in the skill set and talents by the project manager would
radiate and be picked up by the team. On the other hand, bad leadership will surely kill morale.
• Morale is an indicator of the team’s confidence.

• Morale also evaluates the productivity of the team.
• Through effective and confident leadership, morale can be regulated to its fullest and be
relegated to the team.
• What is morale?
• How can morale measure productivity?
• What kills morale?
151
Can You Measure Morale
URL: http://pm.97things.oreilly.com/wiki/index.php/Can_You_Measure_Morale
Quote: “A major role for the software project manager is to create a work environment that fosters the
growth of team morale.” – David Bock
• How to increase the team’s morale.
Review:
High team morale usually equates with high levels of productivity. The project manager should
be able to identify this and use it to its fullest advantage. Here are some tips:
o Empowerment and ownership-entitlement can be given to the team members. This can
mean that the project manager has confidence that the team can make the right call
and justify decisions when time calls for it.
o Defend the team against unjust company policies.
o Establish and maintain a healthy work environment. (See Work In Cycles)
o Encourage activities that promote teamwork.
o Respect their personal lives.
o Constantly question team members on how to increase morale.
• High morale equates to high productivity.

• Involve the team members in the quest to increase team morale.
• What does team morale usually equate to?

• How can high morale be achieved?
152
We Have Met the Enemy…And He is Us
URL: http://pm.97things.oreilly.com/wiki/index.php/We_Have_Met_The_Enemy...And_He_Is_Us
Quote: “Open your mind to this new world of software development, and you can be a support for your
software development team, not the enemy.” –Barbee Davis, M.A., PHR, PMP
• Avoid being a detriment to the team.
Review:
A newly made software project manager will often have plenty assumptions on the team. Some
of these assumptions may work, but generally, these assumptions may do more harm than good.
The following are tips on how to avoid inflicting damage to the team:
o Make the meetings brief but useful.

o Make the initiative to learn a foreign tongue a member might speak.
o Open-mindedness in agile methodology.
o Allow developers to brainstorm, even if they’re away from the computer.
o A developer focused on the task must be left uninterrupted and undistracted.
o Entertain new ideas or tools that the members might suggest.
• Assumptions may do more harm than good.

• Be objective and responsive in making way to avoid causing damage to the team.
• Why can assumptions be harmful?

• What are the different ways a project manager can do to avoid causing damage to the team?
153
154

Great Minds Doing Work

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Great Minds Doing Work

Hochgeladen von

Copyright:

Verfügbare Formate

Great Minds Doing

This book is dedicated to my parents, whose unending love, care, and

To my relatives, especially Anibeth, you all have always been there to

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The importance of managing change in a project.

What I have learned:

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

From the article

• What are the different functions of a work-stream?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The classifications of important and urgent tasks.

• Important and Urgent – Velociraptor attack

• What is the Velociraptor attack in project management?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The importance of the users’ involvement in the project.

• The clients/users should be involved as much as possible in the development of the

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• Business value for projects differ in every purpose/market it is intended for.

• What is business value?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The definition of Fallacy of the Big Round Ball.

• What is the fallacy of the big round ball?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• What is the Fallacy of Perfect Execution?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• How the 60/60 rule help in software maintenance.

• What is the 60/60 rule?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• Clever codes are “evil” to the maintenance and enhancements of a system.

• What are clever codes?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The importance of the World Wide Web to future innovations.

• What is Moore’s law?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

What is an agile methodology? It is an evolving methodology which promotes a software

• Agile methodology is a method or technique in helping facilitate the team.

• What is an agile methodology?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• The proper facilitation of distributed projects.

What I have learned:

• What is a distributed project?

Amazon Link: http://www.amazon.com/Things-Every-Project-Manager-Should/dp/0596804164

What I expect to learn:

• Criteria that deter potential clients from visiting company’s website.

• Start off with a slow loading Flash screen

• Surprise me with startling, ear-deafening video clips.

• Disable the Back button

• Choose a low visibility color scheme