Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘pm’

Are You Cut Out to be a Project Manager?

Posted by iammarchhare on 27 May 2009

On the blog Project Management Tips, Brad Egeland wrote 2 articles titled “Five Signs You Aren’t Cut Out to be a Project Manager” and “Five More Signs You Aren’t Cut Out to be a Project Manager”.  Both of these articles are worthwhile reads.

The first 2 he lists pretty much show that an IT PM’s job is to bridge people and technology.  While people skills are important, they certainly aren’t the only skills you need.  Likewise, a PM in a technical position needs some sort of technology background.  While it is important for an IT PM to be technically minded, it certainly isn’t a necessity to be an expert.  Being an expert can help, as it lends credibility to the PM, but the reality is that the PM must rely upon the subject matter expert (SME) in a given area.  However, to be totally unable to understand the technical team members and to not be able to communicate the information to a business partner, a sponsor, an executive or customer can be a death sentence to a PM career.  This touches a few of Egeland’s other points as well.

In addition to the signs Egeland lists, I would like to submit these 5 for your consideration.  It isn’t that these are any better than Egeland’s lists, but his certainly got my own thought processes working.

Inability to Negotiate

Part of being a manager is the ability to negotiate items.  As a PM, you may need to assist purchasing with negotiating features or price with a vendor.  A PM will definitely be negotiating timelines and resource allocations.  A PM might have to probe into estimates and help come up with alternatives.  A PM will have to set customer/sponsor expectations.

Unwillingness to Continue Learning

Some people graduate college thinking they will never need to learn again.  A PM, though, is constantly learning.  In fact, any IT manager, including an IT PM, has to do double duty on learning because a good PM will be keeping up on the latest technology as well as learning new management skills.

Shady Ethics

Yes, it is a sad statement on the state of the world to even mention this one, but many companies these days have lost sight that the public trust has to be earned.  International companies can present special challenges because graft and “gifts” are taken for granted in some cultures.

Lack of Transparency

This is similar to lacking ethics, but it also includes hiding “bad news” from stakeholders.  This does not mean, of course, that you just bluntly state bad news, but it does mean you don’t try to hide it either.  Bad news has a way of leaking out when it is least convenient.  Unfortunately, I have witnessed executives and product managers that try to cover up the truth only to worsen customer relations in the long run.

Lack of Creativity

Perhaps the most controversial on my list, this item isn’t referring to artistic flair or even to not being able to create an appealing user interface.  Rather, this is the ability to use or reuse technology and processes in some new way.  If you are really creative, it may mean using items in a manner that wasn’t originally intended.  For things that already exist, someone had to be first.  Someone had to be first in applying user supplied tags to objects.  Someone had to be first to take the idea of streaming video and create video conferencing over the Internet.  I can remember using DOS batch files for fdisk-ing and formatting hard drives in a computer lab during bootup because the Novell scripting had limitations that made it difficult in Novell.  Do you have the creativity required to be a true solution provider?

Those are Mine

So, what are some that you have identified as being necessary in order to be cut out to be an IT PM?

Advertisements

Posted in PM Basics | Tagged: , , , , , | 1 Comment »

Use Cases and User Stories – Just Degrees of Difference?

Posted by iammarchhare on 26 May 2009

What is the difference between doing use cases and doing user stories?  Use cases are UML methods of bridging user requirements with a system.  User stories are an Agile way of doing the same thing.  However, throw into the mix that there are formal and informal use cases as well as a use case brief, and you have a potentially confusing situation.

What are the differences between these, then?  Well, Scott Sehlhorst at the Tyner Blain blog tries to tackle this question.  Perhaps they are really just different points on a continuum of overhead and detail.  Throw in the level of reader trust, and you can graph these different items.  “User Stories and Use Cases” is an interesting read.

Posted in Agile, Requirements | Tagged: , , , , , , | 1 Comment »

Consulting Maxims

Posted by iammarchhare on 21 May 2009

If you are reading this, then it is likely I’m either still on the road or recovering from the road trip.  However, this gives me an opportunity to point you to some backlogged bookmarks I’ve built up.

Many PMs are consultants, so TechRepublic’s article on “18 maxims of successful IT consulting” might be of interest to you.

And, if you are not a consultant … well, rethink that, will you?  As I’ve quoted before, we are all consultants in this economy.  Companies can let you go at any time with no reason.

Posted in Consulting, Economy, Employment | Tagged: , , , , , , , , | Comments Off on Consulting Maxims

Earned Value Management Now More Important Than Ever

Posted by iammarchhare on 19 May 2009

Containing costs is a really big deal in this economy.  CEOs and CIOs are not likely to react favorably to unexpected project cost overruns.  Project managers (PMs)  do not want to get caught in this squeeze.  Early detection and mitigation are key factors in a project’s success.

As stated in the PM Hut article “Utilizing Earned Value Management During Economic Downturn”:

Utilizing EVM techniques does not prevent project costs overruns, but it does provide project managers with data for more effective cost and risk management, which has become increasingly important to corporations. Risks that are identified through the use of EVM provide early warning signals that immanent project risks exist.

~ Smith, Kevin.  (13 November 2008).  Utilizing Earned Value Management During Economic Downturn.  Retrieved 12 May 2009 from http://www.pmhut.com/utilizing-earned-value-management-during-economic-downturn.

While the article’s main premise is that company executives will (or will need to) pay more attention to EVM, I haven’t worked anywhere where that was a major problem.

What I find useful is to maintain 2 EVM calculations.  If you have a tool like CA Clarity, then it has a built-in EVM calculator that is rolled up into the various dashboards.  If you do not, then consider which EVM method you want to use to present to the world.  I would pick either percentage or 50-50 methods to present the most accurate data at that snapshot in time.  I would consider this my “tracking EVM” because it is the one being reported and the one everyone will be evaluating you on (officially or unofficially).

However, you, as the PM, need to know even before the rest of the world knows.  Therefore, I have always kept a 100% method EVM spreadsheet to update on a weekly basis to gauge when the project is even thinking about falling behind schedule.  Using this method, you are either late or not on a task.  There is no middle ground.  If you are even one day late, severe penalties are built into the calculations.  Then, you can dig in to find out what is going on underneath the calculations.

Posted in PM Basics, Tracking | Tagged: , , , , , , , | Comments Off on Earned Value Management Now More Important Than Ever

Better Estimating Through Software Sizing

Posted by iammarchhare on 18 May 2009

How do you know how long it will take?  Gut feel is how many do their estimations.

Late last year, I attended a webinar that intrigued me.  I had heard of feature point analysis (FPA) before, but I didn’t know much about it.  I decided to look into it more.

Software sizing is the software engineering term for estimating the size of a piece of software (whether component or entire application).  These estimates then can be used in project management activities.  Software sizing processes are a requirement for CMMi level 2.

Lines of Code

One of the original measurements for coding projects was Lines of Code (LOC).  When procedural languages were the norm, it gave a rough estimate of effort based upon the developer’s output.  With OO software, though, it is a less useful measure, and so it has fallen out of favor in recent times.

In the 1970s, IBM tapped Allan Albrecht to come up with a better tool for estimation.  The result was published in 1979.  He came up with a way of measuring based upon 5 areas:  Internal logical files, external interface files, external inputs, external outputs and external queries.  The Code Project has a 2 part posting that goes into more detail on function point analysis.  Unfortunately, it appears there were supposed to be additional postings that did not occur.

One of the complaints leveled against such measurement is the amount of time required to do the measurements.  However, an experienced person can document one person-year’s worth of effort in about one day.  While some criticisms of function point analysis may be valid, “others are excuses for avoiding the hard work of measurement” (Total Metrics).  There are far too many organizations that would avoid procedures in the estimation process if it took an hour because it would “take too long”.

To me, the biggest disadvantages are the requirements of previous measurements and specialized training.  Previous measurements can be substituted with industry standards, though you will lose the impact of organizational maturity and influences.  Training and experience increase the accuracy of estimates by the estimator.

You also have a catch-22 situation in that functional requirements need to be detailed enough to make an accurate estimate.  No matter the method of estimating, you’ll have this problem, anyhow.  Estimates are improved through the progressive elaboration of requirements.

Both of these disadvantages are quite likely to discourage, rather than encourage, a more systematic approach to estimation.  In addition, FPA is not without its critics for other reasons.  For one thing, best practices in software and the way software is developed is pretty far removed from the 1970s, when FPA was developed.

In addition, project management itself has changed a lot since then.  The concept of FPA might have worked fine with monolithic waterfall projects.  However, with the adoption of Agile by many organizations, such detailed analysis prohibits change rather than encouraging it.

Use Case Points

One alternative to pure FPA is estimation built upon the number and complexity of use cases.  There are tools that can make this much easier, and anyone who understands use cases already can put together an estimate with little additional training.

There is a Windows tool you can use to estimate size with use cases called EZ Estimation at http://ezestimation.googlepages.com/.  I downloaded it, and it looks like a pretty decent estimator that can be used in the requirements gathering phase.

Conclusions

A good plan today is better than a perfect plan tomorrow.

~ George S. Patton

One thing to keep in mind is that any initial estimate is going to be wrong.  That is why progressive elaboration is pointed out in the PMBOK.  One place I worked realized this and broke all but the smallest of projects out into an analysis phase and a construction phase.  The gateway for the construction phase was how the estimate stacked up against the analysis estimate and whether or not the project was still worth it.

The beauty of Agile, of course, is that estimates are adjusted as more is learned.  Estimates become more accurate, as estimates over the life of the project become more accurate towards the end.

If time allows, however, it would seem prudent to do enough analysis upfront so as to be able to hit that middle ground of estimation so that less will be left out in the end.  By doing use cases and using estimating tools based upon that seems to me to be the most reasonable approach.  The larger the project, the more this approach might make sense.  In an Agile environment, this would be done once to get the best possible overall estimate, but user stories, backlogs and adjustments after a sprint would still be carried out on  a normal basis.  The key would be “appropriate detail” in use cases.

I would love to hear anyone’s experience with these.  I have a feeling it depends a lot upon the type of project, the type of customer and the overall project size.


Sources:

  1. Buglione, Luigi.  (25 July 2008).  Functional Size Measurement.  Retrieved 12 May 2009 from http://www.geocities.com/lbu_measure/fpa/fpa.htm.
  2. Cohn, Mike.  (2005).  Estimating With Use Case Points.  Retrieved 12 May 2009 from http://www.methodsandtools.com/archive/archive.php?id=25.
  3. Function point.  (n.d.).  Retrieved 12 May 2009, from http://en.wikipedia.org/wiki/Function_points.
  4. s.kushal.  (11 Mar 2007).  Function Point and Function Point Analysis.  Message posted to http://www.codeproject.com/KB/architecture/Function_Point.aspx.
  5. Software Composition Technologies, Inc.  (June 2003).  Function Point FAQ. Retrieved 12 May 2009 from http://www.royceedwards.com/floating_function_point_faq/about_function_point_analysis.htm.
  6. Software Sizing.  (n.d.).  Retrieved 12 May 2009, from http://en.wikipedia.org/wiki/Software_Size.
  7. Total Metrics.  (June 2007).  Methods for Software Sizing: How to Decide which Method to Use. Retrieved 12 May 2009 from http://www.totalmetrics.com/function-point-resources/downloads/Why-use-Function-Points.pdf.

Posted in Estimating, PM Basics | Tagged: , , , , , , , , , , | Comments Off on Better Estimating Through Software Sizing

When Am I Done?

Posted by iammarchhare on 12 May 2009

The question of “done” comes up quite often.  Ask a developer when the coding for the module is done:

PM: Is the module done?

Developer: Yes.  I finished it yesterday.

PM: Good!  So, it works with the user interface that Jo is working on.

Developer: Well, I don’t know.

PM: So, I thought you were done.

Developer: Well, I coded it.

PM: Did you test it?

Developer: No, but it’s otherwise done.

PM: Well, how do you know it’s done if you haven’t tested it?

You laugh.  Unfortunately, entire projects can be like this as well.

Sponsor: Is the project done?

PM: Yes, it is in testing now?

Sponsor: Well, if the customer isn’t using it yet, how can it be done?

PM: Well, the important parts are done.

Sponsor: But, how do you know it will pass testing?

These scenarios depict the problem of “done”.  Done should be done, and the measurements need to be clear and defined.  “Done” is not some vague feeling.

This doesn’t mean WBS tasks should be a micromanaged checklist of activities to check off.  Each task should be a work package that is identified with inputs and outputs.  Each task should be no less than 1 day in duration, and typical work packages are under 80 hours in duration.  Of course, the larger the project, the larger the work packages may need to be.  It requires a balance between a WBS where tasks can be adequately tracked and having so many tasks that people don’t know which they are really working on.

However, there needs to be a definition of when the task is done.  Scope needs to be clear throughout the project.  Perhaps, a generalization of when a software module is complete:

  1. The test cases are clearly written out according to the functional and technical requirements, along with responses for invalid input and approved by the testing engineer.
  2. The code is written and compiles without error (don’t assume).
  3. The module has been tested and passes its test cases, including those for invalid input.
  4. The module has undergone peer software review and all high priority recommendations have been implemented.

Note the inputs and outputs in each of these.  This is vital.  Notice that each has a qualifier: approval, no compile errors, passes test cases, implementation of peer recommendations.  Safety gates keep low-level scope creep to a minimum.

Setting up and communicating rules for “done” will reduce confusion later and stop additional ridiculous “tasks” (really activities) on a WBS.  Team members should be encouraged to provide any additional rules that may be specific to the project or the environment they are working in.

Note that if, using these guidelines, developers are still hesitant in giving estimates for completion of work packages (tasks in WBS), then identify if the requirements and approach are clear or if there is something missing.

Using work packages allows developers to get the job done without micromanaging them.  Give them a target, and have them aim for it, rather than telling them how to do their jobs.

Setting up and communicating appropriate rules for “done” with a project will similarly reduce nasty surprises at the end of the phase/iteration/project.

Posted in PM Basics | Tagged: , , , , , , | Comments Off on When Am I Done?

Ambiguous Scope

Posted by iammarchhare on 11 May 2009

If you don’t know where you are going, then you won’t know when you arrive.  It really is a simple concept, but it seems to go over the heads of many executives.  Unfortunately, it seems to go over the heads of some IT folks as well.  When that executive wants something and wants it now, it is hard to push back sometimes.  However, “something” is not a scope statement!

If I am dying of thirst, and I ask for a drink, then should I be dissatisfied when I get a cup of coffee instead of water?  Now, I love a good cup of coffee as much as the next coffee addict, but I also know it isn’t going to cure my thirst.  No, I should have been more specific.  The person giving me the drink should’ve asked questions.  Both failed to ask questions, and the task was not a success.

What makes a successful project?  Isn’t it one that delivers the goods?  If you don’t know what the goods are, how do you know when you succeed?  You don’t.  How do you know when you fail?  When you have angry people making demands of you, which is almost a surety if you don’t live up to their expectations.  That is almost a surety when the scope is not properly defined.

Ask the questions on any project:

  1. What is success?
  2. How do you measure success?
  3. When are you done?
  4. How do you measure done?
  5. What is the minimum required?
  6. What is the maximum timeframe?
  7. Can the minimum required reasonably be planned, constructed, tested, reworked and retested in the maximum timeframe?
  8. Will subject matter experts (SMEs) be available throughout the timeframe, or will you have to rely upon less experienced workers?a. Who is indispensible to the project’s success?  When will they most be needed and can you be guaranteed their availability during critical times?

    b. If less experienced people will be used, then is it reasonable that you can still do the minimum within the maximum timeframe?

  9. Are there any stakeholders who do not buy-in on the changes?
  10. Do you have executive support (real, not lip service)?

If any of the above are a concern, and if you cannot come up with a reasonable workaround or mitigation action for it, then it needs to be identified as a risk factor.  The likelihood of the risk occurring must be widely published.  The project sponsor must be engaged with the risk.

Remember that an unmeasurable business goal is no goal at all.  Don’t start out with a hardware or software change as the goal.  No, hardware and software changes may be functional requirements that support the business goal, but they are not in themselves the goal(s).  “Change web interface to make customers happy” is not realistic or measurable.  “Increase online sales by 5% by providing customers online discount codes” is a lot better.  Now you have a business goal, you can start asking the question of where do the discount codes come from, how much the discounts are for and how and when they will be input into the system.

If you started with the interface, then the goal becomes short-sighted.  You may not involve anyone in sales.  You likely would not realize that you needed their involvement until late in the project.  They may be only vaguely aware of your project, and they will likely have made assumptions about how it would work.  The end result would likely be that no customer would receive any discount codes, so sales would remain flat in spite of any work being done.

Even worse, if the project sponsor cannot tell you definitively when a project is done and a success, then your project will have constantly shifting requirements, priorities and timelines.  Force the measurements upfront.  This will force any disagreements among stakeholders to be uncovered at the beginning and not at the end.  This will differentiate between a success or a failure in objective terms.

Measurable goals help to define original scope.  One requirements are mapped to the goals, and as long as the requirements themselves are measurable, then original scope is established.  If there is no way to measure it, then the enduser/sponsor will want additional items put in without effective controls.

Posted in PM Basics, Risk Management, Troubled Projects | Tagged: , , , , , , , , , , , , , , | 2 Comments »

Why the Role of Project Manager is Different

Posted by iammarchhare on 8 May 2009

Earlier I posted about “Why Being a Project Manager is Different” to differentiate PMs from managers.  However, from discussions with some companies over the past 2 – 4 weeks, I have come to the conclusion that many companies just don’t know what a project manager does.

In essence, project management is “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.”  In my article, “What is software project management”, I point out that “Project requirements are the necessary deliverables of the project. Requirements are the answer to ‘what are we making’? [sic]”

Not only does the PM put together a plan that enables an end product, but the PM is also responsible for controlling the cost, schedule and scope of the project itself.

You would think that would be obvious, but you would be wrong.  How do you tell if an ad for a job or a consulting gig is looking for something else?  While any and all of these might be legitimate under certain circumstances, they should be red flags that lead you to question what is meant by them (because there is a good chance the company may not know what they are really looking for):

“Hands on” project manager: What does “hands on” mean?  I consider myself pretty “hands on” because I run the project.  I question people’s timesheets.  I ask them why things are taking so long.  I interfere and get them help if needed.  I do EVM calculations whether you ask for them or not (because it helps me do my job).  Do you want me to code?  Then you are not looking for a PM.  One thing I learned in the Army is that a supervisor doing the work distracts the supervisor from getting the job done right.  If you want a project lead, then why not ask for a project lead?  By the way, unless it is a series of very short projects, the team will almost surely eventually fail doing it that way.  You will still need someone keeping an eye on the forest while your “PM” is looking at the trees!

“Technical” project manager:  This one is similar.  However, it can be legitimate if you have junior people that directly report to you.  If you are wearing both the resource and project manager hats, then you will need extra time for mentoring/coaching, training, etc.  I’ve done this role, and it can be quite fulfilling as long as the organization backs you in both capacities.

Project/Program manager: This one actually may become the wave of the future.  Of course, the caveat is whether or not the company understands the differences and similarities in the roles.  In general, though, there is a larger push for project management to lead into program management.  Some “Sr Project Manager” roles are actually a type of program/project manager amalgam.  I throw this in as a caution that you probe to see if the organization you are getting ready to get involved in knows what the role means.

Implementation project manager:  I sort of hesitated adding this one, as it is a legitimate role on very large projects.  The problem is that I’ve seen it applied to very small projects, and it usually is not justified.  The main question to ask: Are there PMs overseeing the design and construction phases of the project?  If the answer is “No”, then this role is nothing more than someone to blame when everything hits the fan.  2 other important questions to ask are: “Who is responsible for testing and how are the bugs found in the field after implementation tracked back?”, and “Does this role also take over the maintenance phase of the product?”  The former probes into if there is feedback to the correct team (the ones coding).  The latter question tells you if it truly is a project management role, because maintenance never ends until the product support does.  Remember, projects come to an end, even while the product lives on.

I’m sure there are others that are out there.  These were just the ones that particularly stood out for me.  I’d be happy to hear what others may have been encountered.

Posted in PM Basics | Tagged: , , , , , , , , | 3 Comments »

It’s Not Just My Opinion

Posted by iammarchhare on 7 May 2009

Someone actually did a 5 part series of articles on “Why Software Development Projects Fail” that states a lot of what I have been telling people for years:  The need for the correct methodology, the need for enduser involvement throughout the length of the project, the need for special care when using distributed teams and the need for visual prototyping.

Although aimed at CIOs, it is a series that any consultant or project manager should read as a review.  Because, your CIO might not have read it.

I guess my only possible disagreement would be whether or not there really is a need for waterfall in today’s world.  However, I readily concede I’ve never worked for NASA, so perhaps it really does work there.

Posted in PM Basics | Tagged: , , , , , , , , , , , , | Comments Off on It’s Not Just My Opinion

Defensive Programming

Posted by iammarchhare on 4 May 2009

Remember when you learned how to drive, and you had to take a course called “defensive driving”?  You learned to anticipate problems on the road instead of racing down the road assuming nothing would ever go wrong.  By driving in a manner that would put you in the best position possible should something go wrong, you often avoided anything going wrong at all.

Software developers tend to be an optimistic bunch.  Write code for that?  No problem!  Want it in a week?  No problem!  Somehow, they tend to underestimate the power of a computer to do only exactly what it is told to do, whether by their own code, someone else’s they have to interface with or the compiler.

Agile development encourages people to do their test cases up-front.  I am in complete agreement with that concept.

There are problems with that, as there are with anything in life.  In “Developers Can’t Test for Toffee!”, Kelly Waters asks, “Why is it that developers can’t test?”  Waters pretty much states it is the “can’t see the forest for the trees” syndrome.  Developers can only test for issues they think of.  They are down in the bowels of the code, so naturally testers can think of scenarios the developers have not.

Waters makes a pretty good case, I think.  However, my experience is that most developers aren’t trained to think about what goes wrong.  I remember more than one post-mortem where I would ask, “Why wasn’t this accounted for?” and the answer very often was “I never thought that [condition] would occur.”

I guess I was fortunate in that I had a professor who insisted that code ran and produced the expected result.  “Code for the error conditions first,” he used to say.  “Think about what will happen, because it eventually will, when you get in some bad data.  Don’t assume users will input valid data.”

I began to call this concept “defensive programming”.  Anticipate the problems before the best case scenario is even written.

Posted in Risk Management | Tagged: , , , , , , , , , , , , , , | 1 Comment »