On Software Project Management, Part 4

All about CPM and PERT (These are my notes from class, so this post will be “raw” without much thought for grammar and punctuation.)

My oversimplification of this Lesson 03. (Computation of project times is in the lesson as well. Again, slides are courtesy of Professor Rolly Torio.)

CPM – Critical Path Method

  • Used for production management, where repetitive tasks can be determined and there is no need for much estimation.
  • Created by Du Pont for the chemical plants.
  • Focuses on the trade-off between time and cost.
  • Single estimates of derterministic activity times
PERT – Project Evaluation and Review Technqiues
  • Used more for project management, especially for intangible things such as research/development, where a lot of estimation time is involved.
  • Developed by US Navy for the Polaris missile program.
  • Focuses on getting the project done is as little time as possible.
  •  Multiple estimates of probabilistic activity times

Gantt Charts – provide easy graphical representations of when activiites will take place. BUT no details and no relationships between activities.

A Gantt Charts weaknesses may be address using
CPM + PERT (which overtime became one technique), the network technique.

Advantages
-Precedence relationships
-Useful for large projects
-More effecient

Network technique – shows the interdependence of activities through arrows.
Nodes (circle): EVENTS, where activities start or end, a task
Arrows: ACTIVITIES, effort required to perform work, completion of a task

All about the Times
Earliest Time – calendar time where an activity is completed, where all of its predecessor events are completed at their earliest times (best case).
Latest Time – latest calendar time an activity can occur without delaying subsequent events.

Slack Time = Latest START time – Earliest START Time
Positive Slack – amount of time an event can be delayed without   delaying entire project

Critical path:

  • sequence of events where there is NO slack
  • longest path through a network
  • minimum project completion time

Benefits of CPM/PERT:

  • useful in all stages
  • mathematically simple
  • gives time: path and slack
  • project documentation
  • monitors cost

Limitations:

  • clearly defined/independent activities
  • specified precedence of relationships
  • too much emphasis on critical paths

On Software Project Management, Part 3

I have an exam tomorrow about risk management, so I thought I might as well post my notes about it. (So this post will be “raw” without much thought for grammar and punctuation.) These are my notes on this Lecture – Lesson 02, courtesy of Professor Rolly Torio.

First, a recap:

Software Project Management – concerned with making sure that software is delivered within schedule, within budget, and within the requirements specified by the organization.

Necessary because:
Software dev is constantly facing budget and schedule changes
Product is intangible , flexible
Most are one-off projects
Not standardized, recognized with same status as other engineering disciplines (although software does share the many similarities with other complex systems)

PM’s deal most with planning, scheduling, and estimating.

Management Activities include:
Proposal writing
Project planning and scheduling
Project monitoring and review
Report writing and presentation
Personnel selection and evaluation

On Project Staffing
Main problems include: lack of budget to hire great people, or lack of great people.
Can be remedied by training.

Project Planning
Most time consuming
Iteratitive, should be regular updated as more info comes in
Focuses on schedule and budget

Types of Project Plans (QVCSM)
Quality
Validation
Config Management
Staff Development
Maintenance

The Project Plan includes
1. resources available
2. work breakdown
3. schedule

Project Plan Structure
Introduction
Project Organization
Risk analysis
Hardware and software requirements
Work breakdown
Project Schedule
Monitoring and reporting mechanisms

Milestones: end points(most visible with waterfall)
Delivarables: project results

Steps in Requirements Engineering + their corresponding deliverables (FRPDR)
Feasibility Study -> Feasibility Report
Requirements Analysis -> User Requirements
Prototype Dev – > Evaluation Report
Design -> Architectural Design
Requirements Specification ->System Requirements

Tips on Project Schedule
1. Use tools to eliminate time wasted for waiting for processes that do not need to be waited on. Some tasks can be done concurrently. Minimize dependencies to avoid delays.
2. Split project into tasks (1-2 weeks length) that you can easily estimate for time and resources needed.
3. Estimating is hard, but improves with experience.
4. Productivity is not based on how many people are on your team. In fact, adding someone new will make a project later (mongolian horde).
5. Always have a contingency plan.
6. Involves graphs: activities, durations, and staff

Activity Path vs. Bar Charts
Activity paths show dependencies and the critical path.
Bar charts show time against a calendar.

Risk Management
-consists of identifying risks and plans to minimize/avoid/deal with their effects.

“A risk is a probablity that some adverse circumstance will occur.”
Risks affect the schedule, resources, quality, performance, and the business making/buying the software.

Types of Software Risks

The Risk Management Process (IAPM)

Risk Identification: project, product, or business?
Ex. Technology, people, organizational, requirements, and estimation risks

Risk Analysis: assess likelihood and their effects
Probability: very low, low, medium, etc.
Effects: catastrophic, tolerable, insignificant, etc.

Risk Planning: create plans to avoid/minimize
1. Avoidance strategies: how to avoid altogether
2. Minimization strategies: reduce impact
3. Contingency plans: how to move forward/deal with the risk

Risk Monitoring: should be done throughout the project
Regularly  check if probability and/or effects are changing.

Women Who Code: Blogs You Want to Know

According to this article, only a third of women recognized in “women-in tech” type of lists actually code. I did notice that of all the tech blogs I read, I haven’t encountered very many female coders. (Confession: Even my own blog is not that programmer-y.) I agree with the spirit of the article as well. Even though there are more women in technical fields such as social media, user experience, product management, design, etc., we need more women in actual engineering. We need more women coders to encourage the next generation of girls that computer science is not just for the boys, that girls can totally kick-ass in software engineering.

Thus, today, I list a few blogs I’ve found that are written by women coders and software engineers. Reading them has inspired me to continue on my path as a software engineer, and to be proud of my chosen profession. Someday, I hope to be a great engineer like these women are, unapologetically rocking out their diva-ness in a rockstar world.

1. Jean Hsu


Great posts on technical interviews, learning how to code, life of a CS student, etc. My favorite is her post on being a female software engineer.

2. engineers don’t blog


Blog of an engineer who now runs two startups, I admire author Hadiyah Mujhid for being a technopreneur and a coder.
She has a great roundup of resources to help if you have a great idea but don’t know how to code.

3. Vanessa Hurst – Code for Humanity


Insightful posts on the mentoring and the opportunity for women in STEM (scienece, tech, engineering, and math) fields. Check out her amazing post/tutorial on object-relational mappers.

4. Sara J Chips – Girl Developer

Sara J Chipps has great tips on getting starting with MongoDB. Also, you think the guys at Facebook (as seen in The Social Network) the only ones who code “in the zone”? Find out what this coding superstar listens to as she codes.

5. Janet Talks Code

This blog has a lot of technical posts on IDEs, regular expressions, etc. as the author documents her academic career.

6. Sarah Golemon – Still Trying to Get It All Out

Great posts on the nuances of PHP, and even greater tutorials on Zend + PHP  (see her links to her DevZend articles).

Check back tomorrow for Part 2.

On Software Project Management, Part 2

I plan to read all 75 books on Joel Spolsky’s Fog Creek MBA program reading list. However, between my 15 units (plus another 12 I’m taking from other places), plus my writing gigs, I’m not quite sure how long it’s going to take me. Enter Plan B — book summaries. I will be posting links here as I find them (and relevant articles too).

Posting 1-10 for now… I gotta study for my automata theory exam!

1. The Mythical Man-Month

2. Don’t Make Me Think 

3. Growing a Business

4. Dec is Dead, Long Live DEC: The Lasting Legacy of the Digital Equipment Corporation
For now, a review and insights

5. Applied Cryptography (review)
For now, a summary of the field of cryptography

6. Philip and Alex’s Guide to Web Publishing (entire book)

7. Testing Computer Software

8. Design for Community

9. Subversion (entire book)
You may be interested in git vs. subversion and an infographic/cheat sheet.

10. The Non-designer’s Design Book (review + quick summary)

Books 11-20

11. The Pragmatic Programmer: From Journeyman to Master 

12. Measuring and Managing Performance in Organizations (review + quick summary)

13. Facts and Fallacies of Software Engineering

14. Hackers and Painters

15. Competing on Internet Time 

16. The Inmates are Running the Asylum

17. The Design of Everyday Things

18. The Difference between God and Larry Ellison

19. Breaking Windows: How Bill Gates Fumbled the Future of Microsoft (thoughtful review)
On a completely different point of view…more lessons we can learn from Bill Gates.

20. Just For fun: The Story of an Accidental Revolutionary

Books 21-30

21. On a Roll: Or How a Kid from the Bronx Started with Hot Dogs and Wound Up Making a Fortune
Book reviews from Business Week, New York Observer
Great article from Jewish Journal 

21. The First $20 Million is Always the Hardest
Book review (I’m going to really read this book!)
Movie summary 

22. Random Excess: The Wild Ride of Michael Cowpland and Corel

23. Showstopper

24. The Leap
Article from the New York Times 

25. The Hustlers: Living Large and Falling Hard in Silicon Alley
Review
This will actually be interesting to read now, due to the tech boom in New York City [infographic].

26. In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters

27. Startup
A video on the author and the mistakes start-ups make
Excerpt from a Stanford course site (has more resources on the general topic as well)
You might be interested in a summary of Founders at Work. A better one here.

28. Peopleware: Productive Projects and Teams

29. The Macintosh Way
Insights
Twelve lessons author Guy Kawasaki learned from Steve Jobs
Get the entire book for free

30. Microsoft Rebooted
Review + Review

On Software Project Management, Part 1

I’ve always been keenly interested in Software Project Management; this semester, I finally had the chance to take a class! In this “evolving” post, I plan to dump my notes, musings, and links to resources and other interesting things I find on the Web. I also plan to put up a list of the books I plan to read (and their summaries, I hope!).

Lesson 1, Introduction (My notes based on Project Management by Jeffrey K. Pinto and discussions in class)

Definition of a Project:

  • A temporary endeavor that seeks to achieve a goal in mind (deliver a quality product/service to a customer), with the constraints of a schedule, budget, and resources.
  • “A project is a temporary endeavor undertaken to create a unique product or service.” – PMBook 2000
  • “A project is a unique venture with a beginning and an end, conducted by people to meet established goals within parameters of cost, schedule and quality.” – Buchanan & Boddy 92
  • “Projects are goal-oriented, involve the coordinated undertaking of interrelated activities, are of finite duration, and are all, to a degree unique” – Frame 95

The Elements of a Project: complex, limited resources, clear goal, and customer-focused.

The main differences between between a process and a project are as follows:
1. Processes are routine, repeated tasks, while projects are a one-time thing.
2. A Process has several objectives, while projects have one goal.
3. Processes are ongoing, while projects are terminated upon successful completion.
4. Processes are done by people of the same department/skills set (homogeneous), while a project requires people from diverse skills sets and roles to be successful (heterogeneous).
5. A process has systems to integrate efforts, while systems need to be created for a project.
6. Processes have known factors such as time, cost, etc., while these are estimated for a project.
7. Processes use established practices and maintain the status quo, while projects create new practices and upsets the latter.

Why software project management?
We need SPM because software itself is intangible, as well as flexible. A customer may change his mind about the requirements. On top of that, the process of creating software is subject to constraints, such as schedule, budget, and resources.  Furthermore, the practice of software engineering is not standardized (unlike other branches of engineering), posing the need for something that will push for quality at all times.

Activities of a SP manager may include:
1. Proposal writing
2. Project planning and scheduling
3. Project costing
4. Project reviewing and monitoring
5. Project evaluation and selection
6. Report writing and presentation

Concerns on Project Staffing
There may be a lack of budget to hire the people with the required skill set.
Or there may be a lack of people with the skill sets needed. Training recruits is always an option, as well.

Project Planning
-Takes the most time.
-Iterative and evolving.
-Evolves constantly, from initial concept to final delivery.
-Mostly concerned with budget and schedule. (A note on schedules… Most schedules track a maximum of 1 year, 2 years for very complex projects.)

Types of project plans include the quality, validation, configuration management, maintenance, and staff development plans. (We’ll talk about these in detail soon…)

The Importance of Projects
-shorter product life cycles
-helps out with shorter windows for a new product launch
-gives concerted effort for creating complex products
-better collaboration in a global market

The Project Life Cycle
1. Conceptualization. Initial requirements gathering, brainstorming, design. Roles that may be active include the project manager, systems analyst, business analyst, or senior developers/software architects. Deliverables include the business requirement spec, the statement of work, the request for proposal, and the proof of concept/prototype.

2. Planning. Details of the project are finalized. By this stage, you should know exactly what the project should accomplish. Developers, QA, everyone needs to be included in the discussion, as they alone will be able to give an accurate idea of how long this will take, possible problems, etc. Deliverables include the WBS breakdown, the schedule, budget, and a myriad of plans (see above).

3. Execution. Where most of the work happens. Designers design, coders code, QA tests, etc.

4. Termination. The product is handed over to the customer, and resources are assigned to different projects. Deliverables include documentation.

The Constraints of a Successful Project
To be successful, a project must stick to its budget and schedule (as much as possible), without compromising performance. The final product must satisfy the customer.

The Domains of a Successful Project
-Effecient
-Pleasing to customer
-Business success
-Planning for the future
(Efficient product wows customer. The product drives revenue to the customer or simplifies their company processes. They are so happy with this that they go back to your company for future transactions.)

Project milestones – Predictable stages where management can review the status of the product/project.

Risk Management – There may business, product, or project risks. Risk management tries to foresee those risks in order to minimize their impact or avoid them altogether.

Books I am currently reading:

Mastering Project Management