How I learned Function Point Analysis

Posted by Robert Merrill on September 28, 2013 under Business Analysis and Requirements, Estimation | Be the First to Comment

I consider Function Point Analysis one of my secret weapons for software process consulting and project estimation (even for setting up agile projects), and it makes me a much better all-around Business Analyst, too.

Here’s how I learned:

  1. Took a day of training, to get the big picture
  2. Joined IFPUG, downloaded the CPM, and read it all the way through (not in one sitting)!
  3. Muddled through some counts on my own, looking things up when totally stuck, but generally just doing the best I could
  4. Read the CPM again, making notes about all of the things I had done correctly and incorrectly
  5. Did a few more counts, and had a few evaluated by the person who trained me
  6. Registered for an IFPUG conference, a one-day CFPS prep course, and the CFPS exam,
  7. Studied the CPM thoroughly for several weeks, went to the conference, attended the one-day prep course (highly recommended), took and passed the exam
  8. Did a few more counts in the several weeks after the exam to reinforce what I had learned

I found the certification process an essential part of learning. It drives out a lot of sloppiness, and refines your sense of judgement about ILF and RET identification. That was the hardest part for me, and the one that also really influences the results. Thanks to the CPM team for putting those great examples right in the CPM!

It might be different if you worked with an experienced, presently or formerly certified counter who could evaluate your work and give you some coaching—the certification process might not then be essential. Either way, you need someone who knows what they’re doing to evaluate and correct your counting.

I let my CFPS lapse because I couldn’t justify the cost of maintaining it in my own situation—yours may be different. I keep up with the latest CPMs and review them occasionally, but it seems a lot like playing a game with complex rules, once mastered.

Jobs, Projects, or Teams?

Posted by Robert Merrill on September 18, 2013 under Change Leadership, Projects | Read the First Comment

I just read a really interesting article, “Rethinking the Decision Factory,” by Roger Martin, Dean of the University of Toronto business school, on Harvard Business Review (if you don’t follow @HarvardBiz, I suggest it).

When People are Jobs in a Project world

I understand Martin’s main point to be that most businesses think in terms of Jobs, namely sets of responsibilities and tasks with no definite beginning and end. (This is “Job” as in “Position,” not “Job” as in e.g. a print run). But the essential unit of knowledge work isn’t the Job, it’s the Project. Because what makes Projects is beginnings and endings, and some sense in which no two are alike. I think Martin is saying this is a mismatch between the nature of the work and how we organize and (more importantly) think about people.

Martin says there are two downsides.

  1. First, it’s difficult to get the right people on project teams because of the job-centric organizational structure.
  2. Second, it’s difficult to get knowledge workers to share information, or refine what they do that really is more or less repeatable into heuristics (patterns) or algorithms (formulas), because that undermines their Job and therefore leaves them vulnerable in the next round of layoffs. Further, Martin says, the “next round of layoffs” is inevitable, precisely because of the inefficiency and sluggishness of the job-centric organization.

(As an aside, I’ve seen this to be especially true of the specialist and support roles in software shops, specifically project managers and business analysts. The harder it is for senior management to understand what they do—at least programmers “type”—and the more expensive they are, the more likely they are to get shown the door).

Solution: The Project-Based Organization?

What Martin suggests is the Project-based organization, in which a person’s “job description” becomes “execute whatever project we give you next.” As a pattern, he suggests the major services firms such as Accenture and McKinsey. As an example, Martin takes through a year-in-the-life of a junior marketer at Proctor & Gamble, whose Global Business Services unit is considered by Martin to be the vanguard of the new way.

At this point I grow a bit nervous, for three reasons:

  1. Do we really want to pattern ourselves after Accenture and McKinsey? As my colleague Larry McManis recently blogged, “Businesses and Consultants Get an F” for their rate of failed change initiatives, IT projects (tech-enabled business change), and mergers & acquisitions. So I’m not sure that the big consulting firms are who we want to imitate, unless that’s the business we’re also in.
  2. I’m also nervous about the Project as the organizing principle. Projects may have a definite Begin and End (although even that’s questionable), but many seem to have a rather fuzzy definition of Done, or Scope, if you prefer. Projects seem to consist of a somewhat tangled set of outcomes, some of which are clearly essential, others of which are clearly not worth the effort, and a lot more that are in between. And a lot of this no one really grasps until we’re well into them. As much as we try to contain them with gates and sign-offs and other levees, Projects, like rivers, are invaluable but not always cooperative.
  3. Finally, I’m nervous about the “interchangeable-resource” view of people and its ugly stepchild, the multiple-project “resource” allocation. It seems we would rather have fully utilized “resources” and slow teams.

I’ve come to believe that the engine of project productivity isn’t the individual, it’s the jelled, cross-functional team. These take time to form, and have a productivity that’s so much higher than the sum of the parts, maybe 3x, that it seems a shame to break them up at the end of every project.

A Cross-Functional-Team-Based Organizational Adaptability Factory?

What if knowledge work is really an organizational-change factory, not a decision factory? And the central organizing principle isn’t the project, it’s the cross-functional team? And the best way to think about the work itself is as a set of never-ending queues of business forces, constraints, and opportunities, and response concepts, feeding each project team, and resulting in steady streams of (often technology-enabled) organizational adaptations?

I’m no B-school dean, but this is after all the Internet. Food for thought, I hope.

Five Motivations to Lead By

Posted by Robert Merrill on September 15, 2013 under uFunctional Values | Be the First to Comment

I’m glad to hear someone say that different people have different motivations. In “What Motivates You,” Kip Wright identifies five:

  • Getting Ahead. Money, status, promotions.
  • Getting Secure. Finances, position, achievements (like “Getting Ahead” on the surface, but different in the heart)
  • Getting Free. From rules, bureaucracy, lack of control.
  • Getting High. Passion for the job itself and the difference they make.
  • Getting Balanced. Fitting work and family into a balanced whole.

I would take it two steps further.

First, motivations change as life circumstances change. Today’s I’m-the-job, passion-powered 20-something becomes tomorrow’s security- and balanced-minded family provider and parent. They’re still a great worker, just 9 hours a day, not 13. And they’re now informal leaders, have great relationships with peers and customers, and confident maturity. Do you want the option of being able to keep them? If so, your perspective and culture will need to allow for the change. If not, you’ll need a pipeline of passionate 20-somethings.

Second, some motivations are healthier for the person they inhabit than others. Motivations flame out, and take people with them. If your organization allows a person to stop counting on work for things that work can probably never provide, that makes you awesome in my book (for whatever that’s worth). And it probably lets you keep a good employee and spare a good person from a problem they never saw coming.

What’s Wrong with Business Analysts (or Agile / Lean coaches, or …)

Posted by Robert Merrill on September 14, 2013 under Business Analysis and Requirements, Change Leadership, Office Relationships and Politics | Read the First Comment

Julian Sammy, head of Research and Innovation at the IIBA® (International Institute for Business Analysis), compared finding a place to belong as a BA with romantic relationships. One of his conclusions from the latter was that the only common element in all of his unsatisfactory relationships was him. So he looked at himself and learned to be a better partner. He also found a good partner for himself in the process.

In “What’s Wrong With Us?” on LnkedIn, Sammy points to recurrent BA woes—not enough time, indifferent stakeholders, rank-pulling PMs, no time with sponsors, clients who won’t follow the process, etc., and asks, “What if it’s us?” Read more of this article »