Surviving Your Software Project

Boss: I want minute by minute status! (25 of 44)

noreply@blogger.com (Sterg) — Wed, 31 Aug 2011 14:13:00 +0000

Boss: I want minute by minute status! (25 of 44)

In our last episode we were looking for ways to get a project back on track by:

1. Taking tasks out of the schedule.

2. Decreasing the scope of the remaining work.

3. Adding resources.

4. Overtime.

Though these solutions are used quite often in software development projects we stressed that educating everyone on the variability inherent in any schedule especially early on the process and the need to reschedule as the project progresses.

Having said that, once a project goes off course it draws attention.
Project managers should expect to:

1. Meet with the team more often.

2. Report more often to management.

3. Show how you plan to get on track.

Project managers need to prepare and shelter their teams from the added scrutiny. This will not always be easy. Some practices that may help keep the pressure off the team and provide needed updates to management:

1. Adopting a higher frequency of status meetings.

2. Shorter duration status meetings.

3. Increased frequency of reports to management.

Good luck on your projects!

We can schedule and track your next project. Email Us: schedule.trackers@gmail.com.

How are you going to fix this? 24. b) Getting your IT/Software project back on track.

noreply@blogger.com (Sterg) — Fri, 05 Aug 2011 16:19:00 +0000

24. b. How are you going to fix this?

In our last post we discussed, getting you project back on track. Possiblities include:

3.1) Eliminate the work from the schedule.
3.2) Reduce the scope of the remaining work.
3.3) Overtime.
3.4) Add extra time to the schedule.

These are unpleasant choices but schedule slippage happens often. Project managers should be prepared by:

1) Giving estimates in terms of probability ranges.
2) Educating management about the uncertainty in the schedule.

Again, this is not easy to do. No one wants to admit that they are behind schedule. When you are behind schedule, project managers must expect that:

1. Status meeting frequency will likely increase.
2. Options to the get the project back on track will need to development, consult the development team.
3. Management and clients will need to understand the costs and benefits of the current slippage and the costs and benefits of these project changes (we’ll need to discuss change management later).
4. Project managers will need to provide recommendations (see above) to the project back on track.
5. All stakeholders will need to accept or understand the project changes.
6. Project managers will need to document the changes, the feedback from the stakeholders and the changes to the changes!

Before you get behind schedule – at the beginning of the project:
Start educating people early about the uncertainty inherent in projects. Also, the earlier and the more often a project manager refines and breaks down the work, the greater the chance that activities or events that were once vague are now clearer and thus better estimated.

Do not underestimate the power of asking people doing the work to think about whether:
1. They have done a particular task in the past.
2. Have they done something similar in the past.
3. They can on estimate an analysis phase and they don’t know how long something will take.

If they haven’t done the work before, schedule exploratory tasks and re-estimation tasks. If they have:
1. Ask for details.
2. Compare it to the tasks that need to be done.
3. Ask for an estimates for only the immediate next steps and revisit.

Fun Links:

I see quantum objects… http://www.newscientist.com/article/dn18669-first-quantum-effects-seen-in-visible-object.html; http://www.ted.com/talks/aaron_o_connell_making_sense_of_a_visible_quantum_object.html, Aaron O’Connell
Go classify a galaxy! http://www.galaxyzoo.org/how_to_take_part
Play with http://www.wolframalpha.com/ & http://demonstrations.wolfram.com/ - natural language programming
Shai Reshef, an educational entrepreneur-turned-philanthropist, is pioneering an even more radical idea. His University of the People: http://www.uopeople.org
http://edge.org/conversation/geoffrey-west - Why Cities Keep Growing, Corporations and People Always Die, and Life Gets Faster

Your project has slipped. Why? (24.a of 44)

noreply@blogger.com (Sterg) — Mon, 06 Jun 2011 16:33:00 +0000

Your project has slipped. Why? (24.a of 44)

You have discovered that your project is slipping because you can’t meet your bi-weekly deadlines. As we discussed in a previous post, bi-weekly deliverables are a great way to demonstrate and verify progress. So you can’t deliver - what do you do now?

1) Re-estimate by asking the team what it would take to complete the remaining work.

2) Notify management.

3) Make sure you add this time to the schedule.

When reporting to management, include:

1) What work cannot be completed for this milestone.

2) What the additional effort and time is required.

3) What options are available to complete the project and get it back on track. Note, we are emphasizing project success not necessarily successful feature delivery.

Considerations for getting the project back on track:

3.1) Eliminate the work from the schedule.

3.2) Reduce the scope of the remaining work.

3.3) Overtime.

3.4) Add extra time to the schedule.

These are unpleasant choices but schedule slippage happens often. Project managers should be prepared by:

1) Giving estimates in terms of probability ranges.

2) Educating management about the uncertainty in the schedule.

Good luck on your projects!

Links:

http://www.problemsolvingtoolbox.com/index.php Problem Solving 101

Project Management: What’s really done? 23.c.

noreply@blogger.com (Sterg) — Mon, 28 Mar 2011 13:15:00 +0000

In the last post we discussed that project managers should try to get a sense of the rate that project tasks are being completed. This week, we want to discuss how to uncover what features are really done on your software project. One of the best ways of doing this is through a demonstration of the software features completed over a short time period, like two weeks. This should be done in the presence of software product owners as well as the software’s end users.

But how do you get in the habit of showing features in short intervals? Write solid code and deliver “incomplete requirements”. Incomplete requirements acknowledge that it may take several iterations of demonstrating features for stakeholders to agree on what fulfills the user requirements. So, show partially complete features to customers and get some feedback. You may not be on the right track or you might. Taking the time for iterations and product demonstrations is necessary because end users may not know what they want until they see it.

Also, software developers may not understand all the architectural, programming, engineering implications of implementing a specific software feature until they try it.

Finally, frequently integrating and building the software solution is great way of ensuring that the solution can still be build, installed and tested.

Get some something solid but incomplete out the door.

Of course there is the case where you work in an environment where there is a lot of documentation, specifically design documents, user interface documents, framework or style guides. Frequent demonstrations may not be as necessary as more of the decision making has been completed up front. I have never really experienced this even when there was substantial documentation.

The only time a task is really done is when it can be demonstrated and the primary stakeholder or software end user has accepted it.

Links:

http://graphics8.nytimes.com/images/2011/03/13/business/20110313_sbn_GOOGLE-HIRES-graphic/20110313_sbn_GOOGLE-HIRES-graphic-popup.jpg - Engineering better managers? http://www.nytimes.com/2011/03/13/business/13hire.html

Economics Language and assumptions: how theories can become self-fulfilling by Fabrizio Ferraro, Jeffery Pfeffer, Robert L. Sutton. – http://web.nmsu.edu/~yuxia/portfolio/ferraro.pdf

http://www.bighistoryproject.com/ - the history of everything.

http://ycombinator.com/munger.html - Charlie Munger, Berkshire Hathaway

http://www.khanacademy.org – schools out! An extremely useful online school.

Daniel Khaneman: http://www.princeton.edu/~kahneman/publications.html; http://www.ted.com/talks/daniel_kahneman_the_riddle_of_experience_vs_memory.html; happiness; behavioural finance, human behavior: http://www.princeton.edu/~kahneman/multimedia.htm

How fast are we going (project management, project speed, steps 23b of 44)?

noreply@blogger.com (Sterg) — Fri, 18 Feb 2011 19:23:00 +0000

I decided to break apart step 23, Tracking your schedule and watch for tasks slipping (keep checking the critical path) into 3 parts, to give each sub topic some spotlight. We discussed project tracking and tasks slipping on a software project, it’s inevitable. You need to provide task and project durations in terms of ranges and confidence levels. Expect project tasks to slip. How can you quantify where you think you expect to be? Use historical data. As your tasks begin to execute, start keeping track of the number of hours completed against your project and the number of tasks completed against a project. Slowly, you will begin to sense of the number of tasks completed by the team each week, the speed at which your team operates.

For the short term you can extrapolate to guess when the *next* weeks’ tasks will be complete but know that the number of tasks could explode as the project progresses.

Also know that rates of work done will vary as the project progress. Very roughly think of the “S” pattern, mentioned before. Tasks completion starts off slow, picks up speed and then the rate of task completion tapers off.

Good luck on your projects!

How long did it take? (I’m testing a new segment for the blog, trying to give some data on historical projects and what it took to complete them):
Please feel free to update:
1. Specific sub-project name
2. Duration
3. Number of people involved
4. Total resources used
5. Total costs

The Pyramids, (version alpha)
http://en.wikipedia.org/wiki/Egyptian_pyramid_construction_techniques
“In 1997 Mark Lehner and Roger Hopkins, a stonemason from Sudbury, Massachusetts, teamed up to conduct a pyramid building experiment for a NOVA television episode. They built a pyramid 6 meters high by 9 meters square. A total of 162 cubic meters or about 405 tons. It was made out of 186 stones weighing an average of 2.2 tons each. They had a total of just over 3 weeks to build it due to their filming schedule. 12 quarrymen carved 186 stones in 22 days. They were able to erect it using 44 men. They used iron hammers, chisels and levers (this is a modern short-cut, the ancient Egyptians were limited to using copper and wood).”

Links…
Forensic Finance, Benford's Way: http://www.psyfitec.com/2011/01/forensic-finance-benfords-way.html
Book: Dance with Chance – how to live randomness: http://www.dancewithchance.com/links.html
The Truth Wears Off: Is there something wrong with the scientific method?by Jonah Lehrer: http://www.newyorker.com/reporting/2010/12/13/101213fa_fact_lehrer?currentPage=all
http://janemcgonigal.com/my-book/ - gaming to save the world
http://quantifiedself.com/self-tracking-links-to-get-you-started/ - tracking yourself, intriguing…
Spores the game: http://www.ted.com/speakers/will_wright.html
The Upside of Irrationality: http://danariely.com/;

Book : The Wisdom of Crowds,

Economic Outlook Group: http://www.economicoutlookgroup.com/research-reports.php

http://beingwrongbook.com/blog/error-message-google-research-director-peter-norvig-being-wrong, also the book: Being Wrong
To learn, take a test: http://www.nytimes.com/2011/01/21/science/21memory.html
Distributed scrum: http://www.goodagile.com/distributedscrumprimer/DistributedScrumPrimer.pdf

[Marketing to] The bubble generation: http://www.bubblegeneration.com/2009/04/av.cfm

Tracking and slipping (keep checking the critical path). How fast are we going? What should be done? What is really done? (step 23 of 44-ish)

noreply@blogger.com (Sterg) — Mon, 17 Jan 2011 18:37:00 +0000

In our last post we discussed that attempting to define the level of stakeholder engagement for your project will give insights as to what to expect as your project progresses. By asking stakeholders to review the schedule, project managers have a better chance of achieving the project’s goals – even when those goals keep changing. Now, we assume that your project is in the execution phase. In this phase some tasks will be completed as scheduled and some will not. It’s important to note that:

Requirements change causing some deadlines to slip,

Completion dates for some tasks will slip,

_as the project progresses.

This means that critical paths may have changed – the longest sequence of tasks required to complete the project may have changed. What to consider: progress on tasks and dependent tasks will vary throughout the project in unexpected ways. This may not be the case in some industries but it certainly is for IT and software development projects. That’s why weekly, daily monitoring and analysis is critical for early detection of overall project delays. Once you discover a change in a critical path or a set of tasks are taking more time than expected it’s time to look at possible causes:

It there a technical roadblock?

Is there a resource shortage?

Is the full scope of the task only now coming to light?

This last point shows up often in software and IT projects. People don’t always know how long a new software development task will take until they get into it. Project managers will need to revise or rewrite portions of the schedule. This is why it’s important to give delivery dates in terms of a range of dates.

Good luck this year!

Links to make you think, or waste time:

http://www.ted.com/talks/barry_schwartz_using_our_practical_wisdom.html - incentives, rules and practical wisdom.
Learning about statistics: http://www.gapminder.org/
http://www.predictioneersgame.com/blog: “Decision making is one of the last frontiers barely touched by science in day-to-day use.”
http://www.ecb.int/home/html/index.en.html Learning about monetary policy: http://www.ecb.int/ecb/educational/economia/html/index.en.html
www.roubini.com – Economics, Crisis economics
IT Project Management: www.itil-officialsite.com

Stakeholder acceptance of project schedules (23 of 44)

noreply@blogger.com (Sterg) — Fri, 10 Dec 2010 18:56:00 +0000

In the last post we discussed what happens when:

1. Schedules start slipping.
And/Or
2. Features start delivering.

The remedies:

1. Show your features every 2 weeks.
2. Reduce scope if you can, otherwise make sure you take the time to get “accurate” estimates.
3. Work toward “good enough” features that you refine after you release.

This week, we discuss stakeholder approval. What is a stakeholder? Anyone that could impact the schedule and the success criteria: Team members, owners, senior executives, interest groups. How do you get stakeholder approval?

1. Ask for approval via: email, meetings, face to face encounters.
2. Ask for a response by a certain date/
3. Display the results of the approval by all stakeholders, in an email or preferably in a meeting.
4. Get on with the project.

It’s difficult to get all stakeholders to approve a schedule. Most would like the option to say: “I never committed this” when things go bad. Make the attempt to get sign off, document it and proceed with your project. Experiment with talking to stakeholders individually and asking for feedback:

1. What are their concerns?
2. What would it take to get their approval?

Schedule approval is not an easy step. But using the above process will shed light on the level of stakeholder engagement. A lot of stakeholder engagement is mostly a good situation to be in. You’ll get feedback and possibly, resources when you need them. It can also be a bit more time consuming as you will need to obtain more consensuses and require a variety of reports. Sometimes working on project that is part of routine business but not extremely high profile can be a good learning experience without the added pressure of several different “success criteria”. Conversely, a lack of stakeholder interest may lead to slow resource (people) drain and thus possibly poor project performance.

Bottom line, defining the level of stakeholder engagement will give insights as how to expect your project to progress.

Good luck on your projects! On this step, luck helps.

Links that I’d like to Read, Listen to:

http://www.ted.com/talks/william_ury.html - on reaching agreements, from the author of “Getting to Yes”
http://www.stevenberlinjohnson.com/ - where good ideas come from:
Innovation with constraints: http://www.ted.com/talks/view/id/991
Security (yours, your computer’s): http://www.schneier.com/blog/archives/2010/10/me_at_ted.html,
Why most published research findings are false: http://www.plosmedicine.org/article/fetchObjectAttachment.action?uri=info%3Adoi%2F10.1371%2Fjournal.pmed.0020124&representation=PDF
Who said: “The madman is the person that has lost everything but his reason.” ?
The Law of Software Development: http://baselinescenario.com/2010/11/17/the-law-of-software-development/

Present your features. Adjust requirements. Present. Repeat. (22 of 44)

noreply@blogger.com (Sterg) — Sun, 14 Nov 2010 16:36:00 +0000

In our last post we discussed software solution release tasks and some ways to successfully release you solution to your users. A brief review:

1. Plan to do at least 3 iterations to get it right.
2. Build a release checklist.
3. Continuously build and install your software like a real user would.

In this post we will discuss what happens when:

1. Schedules start slipping.

And/Or

2. Features start delivering.

You will usually have a combination of the above. Here’s what you can do:

1. Once every 2 weeks or so demonstrate your latest features to decision makers, end users and ask for feedback.

2. Reduce the scope of the software (or solution) requirements to be able to demonstrate incrementally and deliver to specific deadlines.

Why is this important? Users will not know exactly what they want from a feature until they see working software. So show your software often and ask for feedback. Keep features initially as simple as possible. Then iteratively add more. Simple user and program interfaces that are unambiguous as to their function are best suited for software maintainability and usability.

When should you stop demonstrating a feature and asking for feedback? This is where project managers or product owners need to be aware of the kind of feedback they are getting. Is the feedback regarding basic functionality or about minor changes to the UI? Take good notes as you will need to refer yourself and others to what was agreed upon previously.

The next concept: is the feature good enough? Project managers and teams should avoid spending too much time tweaking features when it’s simply not worth the teams’ time to pursue changes on a particular feature further. Making this assessment comes with experience and good communication. I would agree that it also helps to have a wider funding of software requirements. For example, it is easier to say “enough tweaking” to one user when you have 100 other paying customers.

On the part of slipping schedules and scope reduction, I know that some stakeholders may not tolerate scope reduction but the truth is scope reduction is quite common in software development. Delivering incrementally and asking for feedback from end users is critical to delivering a product that’s acceptable to end user. Effective teams know this. Project managers should educate stakeholders at the beginning of the project regarding the likelihood of scope reduction.

However, if there *is* a low tolerance for scope reduction, project managers need to ensure that tasks are small, well defined and signed off by key stakeholders. It is not a an ideal project predicament.

Bottom line:
1. Demonstrating features often is the best way to show progress and maximize stakeholder buy-in.
2. Scope reduction and feature simplification are effective tools for projects to deliver to robust software on time.

Good luck on your projects!

Links to make you think:

Deep technology thinker, Kevin Kelly’s blog: http://www.kk.org/newrules/blog/ and http://www.geek.com/articles/gadgets/kevin-kelly-explains-technology-at-ted-20100223/
Putting too much emphasis on the data: http://www.kiplinger.com/magazine/archives/investor-psychology-beware-the-pitfalls-of-too-much-information.html#ixzz11VvmdvMn
Gersham’s law” Gresham's law is commonly stated as "Bad money drives out good." The concept, more broadly stated as "the bad drives out the good" can be applied to many things.” http://www.farnamstreetblog.com/mental-model-greshams-law
http://bigthink.com/ideas/18516; Jason Fried, co-founder of 37 Signals and author of Rework. 37Signals is the company that has brought us Basecamp (www.basecamphq.com), a very popular online project management tools. Also, see: Getting Real: http://gettingreal.37signals.com/toc.php
Nudge (that’s the book’s name) and Choice Architecture: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1583509
Procrastination – illuminating insights in procrastination and getting things done: http://www.newyorker.com/arts/critics/books/2010/10/11/101011crbo_books_surowiecki?currentPage=all
How We Learn: “Applications and Misapplications of Cognitive Psychology to Mathematics Education” http://act-r.psy.cmu.edu/papers/misapplied.html
How to focus? http://focusmanifesto.s3.amazonaws.com/FocusFree.pdf
Tom Chatfield: 7 ways video games engage the brain: http://www.ted.com/search?q=tom+chatfield

Book: Rework

noreply@blogger.com (Sterg) — Mon, 01 Nov 2010 17:51:00 +0000

A great read on business development.

Software Release Tasks: You may need more than one attempt. (21 of 44)

noreply@blogger.com (Sterg) — Fri, 01 Oct 2010 17:58:00 +0000

You may not get it right the first time!

We are almost at the end of our first pass of the schedule. Last week we discussed Performance Testing, this week we discuss Release Tasks. What are they?

1. Validated software image, tagged and placed under version control.
2. Validated documentation (Reference Guide, Installation Guide, Quick Start, Online help)
3. New features listed in a document and briefly explained.
4. Release notes added.
5. License agreements have been reviewed and singed off by management.
6. Third party components are properly added (no debug versions unless that is your intent) and licensed.
7. Known issues have been published.
8. All URLs for distribution are verified.
9. Installation and basic tests performed on clean machine and in an upgrade scenario (if appropriate).
10. Backup the release software image and place it in escrow if required.
This type of work lends itself very well for checklists. Project managers need to be prepared that it may take several attempts to get the final software image (documentation, installation, software executables and libraries).

There are different types of releases, really as many as you want: Alpha, Beta, the whole Greek alphabet. These can be considered major releases there are also patch and emergency releases. You will likely be distributing your software over the web and using a specific brand or paradigm (.NET, Java, Open source, existing “cloud” computing environment… many more) so will need to understand the subtleties of the different technologies.

Final note, if you are continuously building your software and automatically creating installable software, your release tasks will be greatly reduced or you will at least be able to quickly recover from omissions and errors.
Good luck on your projects!

Aside: Give project participants a place to publicly commit and pre-commit. This gives participants a chance to deliver ahead of the deadline: http://danariely.com/2010/08/30/back-to-school-2/

More release links:
http://en.wikipedia.org/wiki/Software_release_life_cycle

Time management and estimation:
http://www.pomodorotechnique.com/resources/cirillo/ThePomodoroTechnique_v1-3.pdf

Interesting collection of thinkers: http://www.project-syndicate.org/

The world’s greatest money maker:

Add Performance Testing to your Project Schedule (20 of 44 steps)

noreply@blogger.com (Sterg) — Fri, 03 Sep 2010 14:04:00 +0000

In the last post we added Installation and Deployment tasks to our software project schedule. Now consider this: you’ve worked through your software architecture issues, you have consensus on your user interface, Quality Assurance (QA) has had chance to test the software and Technical Writing (Docs) has started documenting the software. Then one day the Product Manager has the time and the software can be installed without much harm being done to a computer system and finds that it takes FOREVER to do a: simple query, refresh the user interface, or run through any number of files.

Now what? It’s too late! Changes will need to be made to software design or perhaps even the interface. This will have a ripple effect to Quality Assurance and Documentation and even the Software Installer team (or person).

It’s easy to forget performance tasks early in the project, there are so many other things to be done before we can consider performance, like getting working software features to demonstrate. However, it should be assumed by project managers that performance tuning and reworking of design will be required. These tasks should be added to the project schedule.

Most importantly, key stakeholders, end users and Quality Assurance need to specify:

1. How much time is too long to wait for a response from the application?
2. How long should long processing jobs take?
3. How much time should individual transactions take?
4. What is a typical usage scenario and how long do end users expect it to take?

The tasks to add to the project schedule for software performance testing can include:

1. Meetings to discuss the parameters to of interest and their target settings.
2. The software product’s response time under ideal conditions.
3. Response time under “stressed” conditions such as network traffic.
4. A duration, “uptime” tests to observe what happens to the response and resource utilization of the software under long periods of time (1 day, 1 week..)

Need help with your schedule? Email: sterg@lamda-alpha.com

Links:

A great overview of software performance testing: http://en.wikipedia.org/wiki/Software_performance_testing
A fairly comprehensive overview of different software development approaches:
http://en.wikipedia.org/wiki/Software_development_process
Seth Godin’s post on his Project Starting Pamphlet: http://sethgodin.typepad.com/seths_blog/2010/09/launching-the-shipit-workbook.html
Agile Project Management blog Jim Highsmith: http://blog.cutter.com/author/jimhighsmith/
Conducting Retrospectives:
Understanding what the numbers mean: The Cult of Statistical Significance: http://www.statlit.org/pdf/2009ZiliakMcCloskeyASA.pdf

On Creativity and Muse:

Melissa Gilbert on Nurturing Creativity: http://www.ted.com/talks/lang/eng/elizabeth_gilbert_on_genius.html
On Creativity – Amy Tan: http://www.ted.com/talks/amy_tan_on_creativity.html
Jill Bolte Taylor: Stroke of Insight and Nirvana: http://www.ted.com/talks/lang/eng/jill_bolte_taylor_s_powerful_stroke_of_insight.html
Creativity and the brain: http://www.ted.com/talks/vilayanur_ramachandran_on_your_mind.html
All kinds of Minds: http://www.ted.com/talks/lang/eng/temple_grandin_the_world_needs_all_kinds_of_minds.html

Missed Steps 2 of N: Bug Count: Be prepared for a spike in bugs once you’ve hit the 75%-80% mark – add it to the project schedule.

noreply@blogger.com (Sterg) — Fri, 20 Aug 2010 14:24:00 +0000

Project Managers should be always be keeping a list of bugs, issues, new features in some sort of online system. I have used custom systems, Team Foundation Server, FogBugz, and Excel.
All these issue tracking tools work. Some essentials:

1. Bug number
2. Priority, needs to be done immediately
3. Severity
4. Description
5. Steps to Reproduce, this is very important
6. Status, State, (Active, Rejected, Done)
7. Component area where bug is found, UI, Service X, etc.

Also bear in mind that there are different sources of bugs:
1. From users, usually of high priority.
2. From QA doing regular testing.
3. From new features, bugs in the new feature and collateral damage to existing features.

As a project manager, you should be looking at the:
1. Number of bugs fixed in current cycle (Sprint if you’re using Scrum for project management).
2. Total number of outstanding bugs.
3. Total number of high severity bugs that are active, that have not been fixed.

There are many different types of analyses. The important thing is to have to a way to capture and report om the data.

Project managers should be aware that early in the development cycle the bug count could be low but as features become available the bug count will spike when 50-80% of the tasks are completed depending on the types of changes and how quickly they individually take to implement.

Good luck on your projects!

Contact us if you need help with managing your bugs and issues: sterg@lamda-alpha.com.

What are the qualities of a good issue tracking, bug tracking system? Post to this blog.

Useful link(s):

A useful article on how to use Excel’s SUMIF and COUNTIF functions. Great for analyzing data: http://office.microsoft.com/en-us/excel-help/use-the-countifs-function-in-excel-2007-to-analyze-data-HA010236993.aspx

PM Declaration of Interdependence: a great description of the value of project management. Note, I’m not huge fan of declarations, just the description of value: http://pmdoi.org/

Missed Steps 1 of N: Save the Project Schedule's Baseline!

noreply@blogger.com (Sterg) — Thu, 22 Jul 2010 13:47:00 +0000

I’m going to start adding steps in my hastily conceived project life cycle that I have missed. That should keep me busy. One major project management cycle step that I missed is: to save your baseline schedule. Project baselines are snapshots of your project schedule at a specific date. This is important because you want to see how your schedule changes over time and why it changes.

How to save a project baseline in Microsoft Project: http://www.epmcentral.com/msproject/baselinesave.php

How to use Microsoft Project Baseline Information: http://office.microsoft.com/en-us/project-help/view-baseline-information-HP001119045.aspx

Baselines can be an incredible source of information. As a matter of fact, I think project baselines could the focal point for tracking changes in the project.

I suggest you save the baseline every time you update your schedule or a least weekly. This will give you a chance to graph progress over time.

Need help building a scheduling and tracking it? Email sterg@lamda-alpha.com.

Three books and how they relate to project management:

Animal Spirits: How Human Psychology Drives the Economy, and Why It Matters for Global Capitalism: project managers need to know what motivates people and how our animal spirits shape our perceptions: http://www.amazon.com/gp/product/069114592X?ie=UTF8&tag=businfolli-20

The Little Book of Behavioral Investing: How not to be your own worst enemy. http://www.amazon.com/gp/product/0470686022?ie=UTF8&tag=businfolli-20 I think the title says it best: this book will help project managers take a more objective look at their decisions and ways to confront your animal spirits.

Create Your Own Economy: The Path to Prosperity in a Disordered World. http://www.amazon.com/gp/product/B002XULWOS?ie=UTF8&tag=businfolli-20 Yes, the title will mislead you. This book will give the project manager some insight into the patterns and behaviors of the people on your project.

19 of 44 Add Installation Tasks to the Software Schedule

noreply@blogger.com (Sterg) — Thu, 17 Jun 2010 21:32:00 +0000

In our last installment we added documentation to the schedule. Like (Quality Assurance) QA and Software Development, the Documentation (or Technical Writing) tasks can take on their level of detail to the point of requiring their own schedule. The key here is that Software Quality Assurance and Documentation work depend on Software Development – meaning QA and Documentation tasks have dependencies on the schedule. The same goes for Installation and software deployment work.

Though they may seem like a low priority set of tasks (or a mini-project) consider:

1. There is a lot of work involved in building installers.
2. You can start building installer before you finish coding your project and should.
3. The installation and deployment experience for your product will color the overall impression of the ease of use of the product.

Tips for the project manager:

1. Start your installation tasks as soon as possible. You can even use placeholder modules.
2. Automate the build, install and deployment process and add it to your continuous builds.
3. The installer will have its own set of bugs and requirements, assume you need a separate category for the information in your tracking system.
4. Plan for multiple iterations, people love to review installation experiences – show them early.
5. The Technical Writing and the Quality Assurance teams will have input and file bugs against the software’s installer.
6. Uninstalling software cleanly and restoratively is equally important and error prone.
7. Prerequisite checks are tricky and not entirely known when you start developing your software’s installer.
8. The Technical Writing team will take considerable amount of time to document the installer – note the dependency in your schedule.
9. Installer development is not usually the career work that software developers like to do. Project Managers need to be mindful of software developer motivations.
10. Consider deployment and activation: Does your software require remote deployment and configuration? Does it need to be scheduled on the computer it’s running? Does it need to communicate to your server behind a firewall?

I couldn’t find much in terms of generic guidelines for building a good user experience for developing installer and what tasks to consider. What I did find was a bit specific from Apple’s software development site:

http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/XHIGInstallationsUpdates/XHIGInstallationsUpdates.html

Much of these steps can be adapted to all software installation tasks. Project managers should be looking to build checklists and add tasks to the schedule.

Need help with scheduling your installer tasks? We can help: sterg@lamda-alpha.com

Links and posts of interests:

The Checklist Manifesto: How to Get Things Right.
I haven’t been this excited about a book in a long time. As project managers we should be collecting and applying checklists. More posts to follow:
http://www.amazon.com/gp/product/0805091742?ie=UTF8&tag=businfolli-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0805091742
Checklist examples:
http://www.projectcheck.org/uploads/1/0/9/0/1090835/surgical_safety_checklist_production.pdf
http://www.projectcheck.org/uploads/1/0/9/0/1090835/checklist_for_checklists_group_draft_5.pdf

The Halo Effect: One can enjoy business books but question their results if they only look at winners or the causal links they draw from “success” attributes. This will help project managers understand how to interpret success results.
http://www.amazon.com/gp/product/0743291263?ie=UTF8&tag=businfolli-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0743291263

Discover Your Inner Economist, by Tyler Cowen. For project manager’s what motivates you?
http://www.amazon.com/gp/product/B0013VZI84?ie=UTF8&tag=businfolli-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B0013VZI84

We show up as a Squidoo Lens: http://www.squidoo.com/Software-Scheduling

18 of 44: Add Docs (Adding Documentation to your Software Project):

noreply@blogger.com (Sterg) — Thu, 20 May 2010 02:35:00 +0000

(I’m trying out some of the ideas from: Made to Stick: Why Some Ideas Survive and Others Die, by Chip Heath and Dan Heath.
Sorry for the mess.)

In our last entry: Adding Quality Assurance and Testing to the Software Schedule, we concluded the obvious: QA should never be an afterthought in project schedule. The same applies to Documentation (Docs). Before I go off on more obvious statements, what is single best contribution good product documentation can make? Is it excellent prose? Is it an awesome visual experience?

Documentation needs to be accurate, and representative of how the user will use the software. Though this may seem obvious, time pressure and the complexity of software make this hard to do.

The Story: To see why accurate documentation is hard to get consider the following: You’ve hear of a bunch of loose requirements assigned to the development team. The development team is busy build up code base. As features become available, the QA team has started testing early features. Now what? Enter Documentation. When the QA team has looked at a feature and deemed it workable then and only then should the Docs team start playing the feature. You may want to get Documentation in earlier but unless the team can contribute or record the proceeding accurately, their time can better used elsewhere. The QA team will be the bridge between the developer and documentation team. This isn’t a hard rule but useful one. A Doc team should be able to take working features and try them out. This is simple statement but hard for anyone not immersed in the product to do. A lot of software requires many setup steps to put in the proper state before you execute a particular feature. The build-up and tear down skill set for this is not always available in the Docs team. In some cases you can outsource this skill to the QA or Development but this is draining on smaller teams. In some ways the Docs team will act as an extension of the QA team. As Docs team tries the feature(s) they will:

1. Update the user and reference manual as well as install guide.
2. File more bugs.
3. Ask for feedback, interview team members
4. Ask for reviews.
5. Publish their work.

Answer to the mystery: So the best thing a Docs team can do is provide accurate timely, content on how to use the product. There isn’t much more to it. You’ll know it’s good when support people get feature requests and not how-do-I-do-this questions. WIIFY: Providing accurate, up-to-date, how-to descriptions of your features will make for satisfied customers and relieved support staff. Both can be profitable.

Ramblings and Related Topics:
Jacob Kaplan-Moss one of the maintainers of Django writes: “Write in short paragraphs. If you compare good documentation to a typical magazine article or book chapter you’ll quickly notice a big difference in paragraph size. A book might have paragraphs that are ten, twenty, or dozens of sentences long, but it’s rare for good online documentation to even measure up to half that. The longest paragraphs in this document are about five or six sentences long…“
http://jacobian.org/writing/great-documentation/technical-style/

For those that are web building web apps, here are some marketing tips that could help with documentation: http://web.appstorm.net/roundups/design-roundups/10-marketing-resources-every-app-should-provide/

We’re working on new site, check out: www.schedule-tracker.com

Posts, Blogs of interest:
Microsoft Project 2010: http://blogs.msdn.com/project/archive/2010/05/18/project-2010-introducing-inactive-tasks.aspx

Ian Brenner, International Risks: http://eurasia.foreignpolicy.com/blog/2193

The No-confusion Timeline Report: http://blogs.msdn.com/mvpawardprogram/archive/2010/05/19/10-days-for-office-2010-be-more-productive-with-office-and-project.aspx

Loading...

Contact us, tell us what you think!

noreply@blogger.com (Sterg) — Wed, 05 May 2010 16:32:00 +0000

Scheduling, tracking so you can achieve:

We schedule and track your software and IT projects. This will give you more time to focus on the technical aspects of the project and managing your teams.

Your Partner in Project Management.

Your Success:

Your schedule is your team's map to success. Success is delivering your application, product, solution to your customers when you want to. We'll help you build a schedule or use your existing template.
A schedule gets you on the path to success. We'll track your project...
You don't have time to build and track a schedule, you are focused on delivering your project. We do it for you!
You may have a small project that requires a part-time project manager.
Consider the cost of not knowing if you can deliver to your clients, customers or users when you want to...

We can use your favorite online project management tools to track your projects:

contact: sterg@lamda-alpha.com

17 of 44: Add QA (not afterthought!)

noreply@blogger.com (Sterg) — Thu, 22 Apr 2010 09:27:00 +0000

Quality Assurance and Testing should never be an afterthought in project schedule. We present it here as your QA team will start testing the software as individual features are available for Show and Tell. Show and Tell, demonstrating features as early as possible in the development cycle, is essential in software development as users often don’t know what they want until they see it. This was the topic of our last entry. This week, let’s discuss QA and its impact to the schedule. The topic of QA in software development is massive and we won’t be delving too much into specifics.

Some items to consider for your schedule, specific to QA:

1. Test planning, setup, development, execution and reporting.
2. Bug submissions and reviews.
3. Development rework, retesting features.
4. Nightly/continuous build testing.
5. Release testing.

Let’s look each of these and their impact on the schedule.

1. Test planning, setup, development, execution and reporting. These tasks are analogous to development work. On the schedule you can add these tasks to specific features or feature groups. You may also develop a parallel sub-schedule that has dependencies on development milestones (I prefer this method as it makes the schedule cleaner). Similar to development tasks, you should get estimates from QA people (those doing the work), otherwise use some standard defaults. Often, there is a relationship to the amount of development work and the amount of QA work.

2. Bug submissions and reviews: bug submissions and reviews can be costly but they are necessary. QA and Developers need to submit bugs, meet and review them, prioritize the bugs and then schedule a new release of the product for testing and general release.

3. Development rework: Often this work needs to be scheduled after the original schedule is put in place. This is usually unpopular. You can model this by adding buffers to high risk task and then replace the buffers by specific tasks.

4. Build Testing: After bugs have been fixed, there is usually an automatic build triggered. Testing the software’s baseline functionality and testing for fixed bugs takes time. This is where automated testing can save some time but maybe not as much as you think. Bug fixes are notoriously hard to automate in some instances. It’s easier to automate testing when you’re testing a new block of functionality.

5. Release testing: This is testing of the final product to be shipped to customers. It takes a few tries. This may also be the first time that the quality of the release notes, documentation, and the proper position of files is evaluated. I usually estimate at least 3 tries at getting the final release image right.

It’s incredibly easy to underestimate the amount of QA work involved in the software development cycle. Treat it like a separate, dependent-on-development project and you won’t be too far off in your overall schedule estimates.

16 of 44: What's the most important stuff the customer wants? How soon before we can just SHOW that?

noreply@blogger.com (Sterg) — Fri, 26 Mar 2010 16:14:00 +0000

In our last step we discussed what things will likely happen on the project that will cause delays and what we guess could possible delay us on the project. As project managers, we are looking for clues, phrases from management and the team, that may make us guess that work will take longer than it’s expected or that resources are about to be reshuffled. It’s guesswork.

This week we want to discuss: show and tell and doing first things first. All you needed to know was learned in kindergarten. When building a schedule you need to be aware of both the sequence, the way things get done, and the priority of the features, what’s important to stakeholders or customers. You may be trapped into a certain sequence to getting the work done but you are tring to get important features done first.

As the features are being completed, they need to be completed in a way that can be demonstrated to stakeholders. Schedules need to reflect these demonstrations (Show and Tells) as milestones, and time allotted for rework and refinement of features. As a very rough rule you should be able show a feature to stakeholders approximately 2 weeks after the project execution has started. If not, question why it can’t be so. You may get answers like it’s technically infeasible or there will be nothing to show. Counter this initially by digging into the requirements with questions requirements like “why can’t we show (just) this?”

Step 15 of 44: What don't we know? Are we trying something new for the first time? Is this the first time someone is trying this?

noreply@blogger.com (Sterg) — Mon, 15 Feb 2010 21:39:00 +0000

In step 14 we discussed what to consider when being asked to add team members for the purposes of compressing the schedule. Adding team members are a form risk and this is the topic of the next step.

There are of number of ways to assess risks in a project and maybe later we’ll dig deeper. For now we are looking for events we are expecting to happen and events that we can guess will happen. Let’s examine both:

Events we are expecting to happen in a project:
1. Customer support.
2. Vacations.
3. Leave of absence.
4. New projects.
5. Team members leaving.
6. Not integrating as expected the first time.

The above cases can be modeled with non-working time in the schedule, as a contingency time (buffer time) or as a range of dates when a milestone will be achieved. Buffer time is controversial in most organizations but it’s naïve to think that a particular project will be immune to customer support or people leaving. Leave the buffers as separate items on the schedule and be prepared to talk about range of dates with buffer and without.
Events we guess will happen. This is a class of risks that require project managers to be more knowledgeable regarding team and company culture. These risks could include:

1. The experience of team members.

2. Management type: There are many ways to look at how management style will affect team performance or how management will add risk to the project. For this discussion consider managements that routinely change team size or product review teams that take longer than necessary to review working features. Either can be modeled by producing schedules with fewer resources or providing iterations in schedules (repeating certain tasks in the schedule).

3. Degree of “newness” to the project: Team members that are new to a certain type of task or a new integration or SDK task is being attempted, should raise that flag that potentially more time will be required than scheduled. Project managers should be listening for conversations that contain phrases like:
a. “We/I have never tried this before.”
b. “I’m sure not this will work I’ll have to try it.”
c. “We may take a performance hit on this.”
d. “This is a brand new SDK/language/.”
4. It’s best to model the above with iterations usually 1 to 3 iterations. Also, this is a good opportunity to ask what would happen if the “new thing” was abandoned.

Need help putting together your schedule? Email us: info@lamda-alpha.com

Online tools for tracking your project (we handle set up and tracking for you):
www.wrike.com
www.5pmweb.com
www.basecamphq.com

Step 14 or 44: Can we add more people to the schedule to speed things up?

noreply@blogger.com (Sterg) — Fri, 08 Jan 2010 14:36:00 +0000

In our last step, “what can be done in parallel (out of sequence)”, we made a number of considerations regarding when a set of tasks can be done in parallel. We also discussed that we may need to challenge norms if we plan to move sequential work and attempt to do it parallel. Note, there usually are reasons that work should be left as it is and the benefits of moving to more parallel work could easily be overstated in a schedule. Further, project managers may be pressured to add more people to the team in order to theoretically increase the speed with which tasks can be completed. On paper this will seem to work but in reality you need to consider:

1. Team member experiences.
2. Task dependencies.
3. Team dynamics.
4. Individual team member throughput.

Let’s look at each of these briefly:

1. Team member experiences: This is all about matching the capabilities of developers with the tasks to be assigned. It comes from understanding what a developer’s experiences are and matching that with the task they are most likely to succeed in completing.

2. Task dependencies: When assigning tasks to newly added team members, it’s important to understand the relationship between tasks. Speeding up one group of tasks may result in bottlenecks elsewhere (Quality Assurance, User Interface Development). Also, some tasks need to be completed in sequence, making the process of adding new team members less effective.

3. Team dynamics: Adding team members that require additional ramp up time or that may be disruptive, may slow the project down.

4. Individual team member throughput: Based on a team member’s historical performance, current commitments (vacation, product support), and expertise, project managers need to make realistic decisions on whether work can be completed based on an estimate. Perhaps the easiest question to ask is: given past performance can this work be completed as planned?

Schedule. Track. Achieve: sterg@lamda-alpha.com

sidebar: SuperFreakonomics and Project Management

noreply@blogger.com (Sterg) — Fri, 11 Dec 2009 15:23:00 +0000

This type of book is designed to make you think. Here are a few ideas inspired from book that could apply to project management:

1. Ask questions about effective project management whatever that means to you. Then get data that may help answer those questions.

2. Analyze the data you have. Keep historical data and use it to make decisions about future projects. Taking a closer look at data may reveal things aren’t what they seem.

3. Systems respond to incentives. The trick is that the response may not be what you expected and what responds may not be what you expected. Specific to project management, people respond to incentives but not always in the way you would expect. Consider the law of unintended consequences.

4. Simple, transparent solutions are wonderful (but rare).

5. Keyboards are a breeding ground for pathogens. Wash your hands often :-)

Step 13 of 44: What can be done in parallel (out of sequence)?

noreply@blogger.com (Sterg) — Mon, 30 Nov 2009 15:31:00 +0000

In the last post we discussed tracking. Some work items will often:

1. Take longer than anticipated.
2. Just not get done.

Then we came up with some ways you can incorporate these findings into your schedule.

This week we discuss what can be done to “save time” by doing work in parallel. I put saving time in quotes because the exercise may not save time by itself but it is still useful. What does doing work in parallel mean for us? It means taking tasks that were supposed to done by one person, assigning them to more than one person and executing the tasks independently of each other. This example can be extended from individuals to groups as well.

Some questions to consider:

1. What is my critical path? Assigning tasks that are not on the critical path to new team members will not shorten your project cycle. In Step 7 we briefly discussed critical paths. The important thing to remember:

a. “Calculating Critical Paths can be tricky. For small, simple schedules look for the longest path through schedule.”

Looking at what can be done out of sequence is a useful exercise in that it makes a team take a closer look at the project elements (architecture, process, resources).

2. Can the work be actually performed out of sequence? Some work items will seem like they can be done in parallel when in actual fact they cannot. This is where discussing the work with senior people is important.

3. Consider individual workloads. Giving work to someone that is unfamiliar with the task is not going to make the project go faster. Giving work to some that is already bogged down with work will not make the project go faster.

4. Creating a new critical path. There may be multiple task sequences in your schedule. By shortening one, you may reveal the next longest sequence in your schedule or inadvertently lengthen another (for example the testing cycle).

Prepare everyone for the debate about what can be done out of sequence. Some people don’t like change or doing things out of order. As a project manager be prepared to ask: why not? Make this an innovation challenge. Perhaps there is a way to develop a totally new process or tweak an existing process that will enable more people to work independently and out of sequence.

We'll discuss a output of this process next week, the question: Can we add more people to the schedule to speed things up?

Need help with your schedule? Email sterg@lamda-alpha.com

Step 12 of 44: That won't do, let's take a closer look at what's slowing things down.

noreply@blogger.com (Sterg) — Fri, 06 Nov 2009 14:28:00 +0000

As the schedule progresses you will notice:
1. Work that’s taking longer to do than anticipated.
2. Work that’s just not getting done.

In the case of work that’s taking longer than anticipated, try to figure out what causing the delay:

1. New work that wasn’t estimated. For example A and B were planned for but A, B, C, D is what is required. This is a typical and uncomfortable situation to be in. You can:
a. Replan with the new work – unpopular with management.
b. Work with the team to reduce scope.
c. Work with management to reduce scope.
d. Add more people – tricky.
e. Work more hours – unpopular with the team.

Typically the answer will lie in some combination of the above.

2. In the case where the work is not going as fast as anticipated. This could be due to:
a. Team members being pulled off to support existing customers – typical.
b. An inexperienced team member – even experienced developers haven’t seen everything.
c. Increased wait times for feedback – common and easy to forget to plan for.
d. Vacations.
e. Team member absence.

For the case of work that’s just not getting done consider:
1. Is the work still relevant? Can it be dropped?
2. Is the work in the wrong sequence?

Often you will find in software projects, that there are things that won’t get done because they are of lower priority. It’s a judgment call whether the work should be dropped from the schedule or added to the next cycle.

The important thing to remember is that you shouldn’t wait to address work that is not getting done or is delayed. The team will need to answer for it in one way or the other.

Stergios Spandonidis
Project Manager
sterg@lamda-alpha.com
www.lamda-alpha.com

Loading...

11(a) of 44: Is It Really Done? Defining DONE.

noreply@blogger.com (Sterg) — Wed, 21 Oct 2009 13:59:00 +0000

Quite often you will notified that a feature or bug fix is "done". This is when it's important to have a standard definition of, DONE. For a developer it may be that the code compiles. For stakeholders it may be: the feature does exactly what I want it to. Here are some things to keep in mind for your definition of done:

1. Is there a unit test for the feature/bug fix?
2. Has there been a code review?
3. Has Quality Assurance tested the feature?
4. Has the feature been demonstrated to primary users?
5. Has the feature been documented?
6. Has there been a unit test created for the feature or bug fix?

There's likely more items you can add to this list. Whether you add these items to your schedule or checklist is up to you but you will need some way of way tracking these steps.

Good luck on your projects!

sterg@lamda-alpha.com
www.lamda-alpha.com

Step 11 of 44: How long will it take?

noreply@blogger.com (Sterg) — Thu, 15 Oct 2009 12:45:00 +0000

Be prepared to reschedule the latter half of your schedule.

At this point in the schedule’s execution and probably until the end of the project, you will be asked: How long will it take?

Some things to consider:

1. Have meaningful statuses at least 1 once a week

2. Tailor your status for each type of stakeholder.

3. You may have to reschedule.

This last point may need further explaining. When a project begins you may have a vague idea on how later tasks will unfold but as the schedule progresses you will:

· Have a better understanding of what needs to be done; you may be able to simplify your schedule.

· You may need to add totally new tasks to the schedule.

Rescheduling is something that happens more often than we would like to admit in a fast paced environment where no two projects are alike or when compromises need to be made.

------------------
Need help rescheduling? Want to offload the scheduling work? email us: info@lamda-alpha.com
www.lamda-alpha.com - Schedule. Track. Achieve.