EppsNet Archive: Project Management

I Think We Are Kidding Ourselves

7 Sep 2015 /

More people have ascended bodily into heaven than shipped great software on time.Jim McCarthy

Ascension

On the other hand, the number of people on LinkedIn claiming to have a demonstrated ability to lead software projects to successful completion, on time and on budget, as well as the number of companies seeking to hire such people, is infinite.

Thus spoke The Programmer.


9 Links

1 Mar 2014 /
  1. Data Structure Visualizations
  2. Good Tech Lead, Bad Tech Lead
  3. Google Java Style
  4. Guide to 12 Disruptive Technologies
  5. How to Write a Cover Letter
  6. The Landing Page Optimization Guide You Wish You Always Had
  7. Selendroid: Selenium for Android
  8. UX Axioms by Eric Dahl
  9. Yelp’s got style (and the guide to back it up)

Misled by Metrics

19 Nov 2011 /
Budget

Image via Wikipedia

From a Sr. IT Consultant:

I recently asked a colleague [CIO] whether he would prefer to deliver a project somewhat late and over-budget but rich with business benefits or one that is on time and under budget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.


Jeff Sutherland: Scrum: Why Story Points Are Better Than Hours

Posted by on 28 Oct 2011

The Essence of Scrum

28 Oct 2011 /

Good short article by Tobias Mayer on the principles of empiricism, emergence and self-organization, and the mechanisms of prioritization and timeboxing.


Don’t Know What You Don’t Know

24 May 2011 /

It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.

Lost

Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.

The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.

You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven’t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.

— Jim McCarthy, “21 Rules of Thumb for Shipping Great Software on Time”

Kanban, Scrum, User Stories, System Design

24 Apr 2011 /

A Longstanding Absurdity

12 Feb 2011 /

Is the bad-software problem really caused by bad requirements definition, which we could fix by doing a better job up front, if only we were more diligent and more professional in our work?

We have made this our primary excuse for bad software for decades. If this was really the problem, and if processes focusing on early lockdown of requirements provided the needed solution, wouldn’t we have solved this by now?

A process that requires us to lock down decisions early will maximize our risk, not manage it.

Cem Kaner

Middle Management

5 Oct 2010 /

In most failing projects, there are a few people at the top of the organization who think they are in trouble, lots of people at the bottom who know they are in trouble, and a bunch of worried middle managers trying to keep those at the top from talking to those at the bottom.

— Ken Orr

Don’t Look Back

12 Jun 2010 /
Looking back

In uncertain conditions the main question should not be: “Why didn’t your performance yesterday conform to the original plan?” Rather, it should be: “What kind of feedback can help you learn faster and perform better tomorrow?”


The Illusion of Control

11 Jun 2010 /
Paperwork

More paperwork does not ensure greater information reliability or accuracy — it only adds to the non-value-added cost. It only seems that adding more measurement and reporting means better control. The illusion of control may partially explain an obsession with control.


Stand Up for Your Opinion

10 Jun 2010 /
Negotiation Breakdown

In areas critical to the success of the project, stand up for your opinion. When necessary, challenge senior management and negotiate project objectives or the resources needed to accomplish them.


How to Get on My Bad Side

9 Jun 2010 /
Couple Yelling

Walk into my office the day after your project is approved and say, “When are we getting a team together for my project? Because I don’t plan to miss my deadline.”

Slap the back of one hand into the palm of the other for emphasis.


Optimal Solutions

9 Jun 2010 /
Don't Stop !

Even in situations where information is missing and changing, and when there is a great demand for speed, it is essential to identify areas where the search for optimal solutions is worthwhile. Being selective is the key.


Convergence

8 Jun 2010 /
8mm Fisheye Test

The distinctive conduct that marks successful project teams is this: They know there is a time to diverge and a time to converge. That is, in each of the project planning phases (e. g., feasibility, conceptual, definition, execution), the team first moves outward (diverge) to gather information and ideas and to generate alternatives — only then does the team move inward (converge) to focus, evaluate, and select.


The Ultimate Goal of Planning

7 Jun 2010 /
Events Calendar

The ultimate goal of planning is the implementation of plans. One is interested in the planning process and its product — the plan, only insofar that it leads to the effective execution of the project.


Flexibility

6 Jun 2010 /
Alyssa, professional dancer @ Central Park

The customer’s needs must dictate the project’s objectives, and in a dynamic environment, invariably one of these objectives is flexibility.


Early Planning

5 Jun 2010 /
Una semana es... un tiempo prudencial

The maximum potential for influencing project outcomes occurs early in the conceptual and definition phases of the project. Autopsies of most failed projects indicate that the disasters were “well planned” to happen from the start. Therefore, even in an era of uncertainty and accelerated speed, don’t rush to execution with only superficial preparations — invest quality time in early planning.


The Goal on a Project

26 Feb 2010 /
Jim McCarthy

The goal on a project is not to have the correct plan in advance but to make the right decisions every day as things that were unknown become known.


A Project Management Question

14 Dec 2009 /

Which is better:

A. Telling a project stakeholder that his good idea is never going to happen?

B. Letting him think it is going to happen when it isn’t?


Next Page »