Properations

I made up the word 'properations' - for the situation where you find yourself in that no man's land between projects and operations.

Have you ever found yourself in this situation? The project should have finished, but just keeps on going? The scope is creeping you out, the client just isn't ready to take on the product, you just can't get that last sign-off...

For whatever reason, you just can't get to "done."

What did you do about it?

How can we avoid this situation?

Project Management
Business Analyst

Reader Survey: Planning orientations

For the third Better Projects site survey I asked about planning. Specifically, the question was about how you orient your planning activities.

“Think about your work (project?) plan. Are you focused on activities or outcomes? Be honest now.”

I had 63 responses and they cam back like this;

• Activities (Process drives consistent quality)   19 (30%)
• Outcomes (Start with the end in mind)   34 (53%)
• What plan (I'm adaptive)  10 (15%) 

What Plan?
The 10 responses to what plan are a bit alarming for me!

If this was your response do me a favour – reply to this blog post and tell me why.

My assumption is that you answer was either tongue in cheek, or you really don’t plan your work (and I expect you are more likely in the BA reader pool than the PM audience.

BA’s – you should be planning your work in as much detail as anyone. It’s complicated, and dependent on many external factors. As a result planning is a vital activity to help your work integrate into the overall project schedule and expected outcomes.

Activities versus Outcomes
Well, people...

The research has been done and while at a macro level, process orientation is important, and possibly even a long term indicator of success, the important thing for projects is to focus on outcomes. It’s even one of Stephen Covey’s seven effective habits; ‘Start with the end in mind.’

For further information on this idea take a look at Josh Nakivel's blog.

Now, if you disagree - I'd love to hear your argument for a process over outcome orientation.

Are you 'On Strategy'?

Businesses have strategies.

Most of these strategies are implemented by projects.  If you are doing something that is contrary to, or not aligned with the organisation's strategy, we could say your project is a waste of resources.

Depending on how far off strategy you are probably has some relation to the amount of waste you are potentially creating.

How on target is your project?

Project Management

Business Analyst

This month's reader survey

This mohth's reader survey is about how you plan your work. The survey form is over to the right of this page.

Share your experiences and knowledge with us.

And of course comments are always welcome!

Project Management
Business Analyst
Image from freephoto.com

Rapid Project Inception

This presentation is by our blogger friend Raj Singh, from Thoughtworks. In it he proposes a structured, rapid, project initiation process (3 weeks.)

This closely aligns to approaches I use, although I tend to take longer but be less intensive.

Intensive? Yep; this model hopes for a full time three week commitment from key stakeholders.

I hope you find this slideshow informative.

SlideShare src="http://static.slideshare.net/swf/logo_embd.png"> View Upload your own

Project Management
Business Analyst

How was your Friday?

How was your Friday?

8.59 Walk onto the floor

9.00 Park at my desk and eavesdrop on developer team not-scrum next to me

9.15 Have a BA advise me on a scope doc for a work package – sign it

9.30 Check with dba on his data cleansing tool; it involves a lite-app with an ugly user screen where they’ll check and modify some dodgy data – I suggest he puts a pretty picture on the screen (nature, dolphins, no, even beter puppies. ) I don't think he buys into the idea.

9.40 Go get coffee for me and lead BA.

10.00 Sit at my desk and wonder what to do with all the emails hat have accrued since lunch yesterday.

10.10 Go for a walk around the floor and say hi to a few of the team members.

10.30 Call three of the team into a room and deal with a boundary dispute – people are disgruntled because of the way the work is playing out. Part of it is my fault for (a) not having published a detailed plan for them to references and (b) for not providing enough oversight – keeping an eye on the big picture. There has been some scope creep. A hard thing to manage as there was no structured goal setting or requirements statement when I joined just a few weeks ago.

11.00 Remind one of the attendees at our little conference they have a meeting with our leading dysfunctional vendor.

11.30 Wrap up the unresolved meeting; more coffee.

12.00 Sit at emails and start filing them- saving a bunch of files to a folder for part of a project review (An 'As is' organisational analysis.)

12.30 Lunch with wife and baby in the park.

1.00 More execution of soft skills, remind people they are valued and loved

2.00 Database design meeting; Agenda: who are the external stakeholders, what design principles should we be applying. Instead we identify trouble rolling versions out to through the various dev and testing environments and try to tackle this issue. We are uilding two applications and have a backlog of versions we can't roll out because of our leading dysfunctional vendor. We also talk about setting up an environment for production support.

3.00 Read over some emails about our leading dysfunctional vendor. Think about what can be done. Have a look at my calendar for next week and wonder how I’ll get the required work done. (There is no plan yet.)

3.40 Take a walk with a develop team leader; talk about what we plan for two new staff who are staring next week.

4.10 Get another call from a key stakeholder for the project review meeting. They don’t have Monday’s session in Outlook and definitely won’t be there. They are one of several with this issue. I try to reschedule. I find a likely time on Tuesday but there are no meeting rooms. I check nearby buildings for rooms. I can book a 200 person room across the road – with coffee and cakes.

4.57 Sure why not. There are 12 of us. It’s booked.

5.05 Leave the building (Friday)

5.30 Get home, dinner, play with child, etc

8.15 Draft a blog post

8.30 Remember my steering committee action for today was to draft a letter detailing our leading dysfunctional vendor’s failures to date

8.45 Save draft blog post. Good night.

Based on a true story!

Project Management
Business Analyst

Picture pinched from Pinky Rocco's blog

which has a piece on stress relief here.

Scrum, Plans, Slack and Contracts (via Wegner's Lemma)

Today I have a question for Josh Milane, author of the MIT Technical blog.

Josh,

(I wish I could post comments to your blog. I really do. Somehow I have to log in and my existing wordpress account won’t do the job… I guess we have to communicate the old fashioned way; via trackbacks and RSS feeds.)

Anyway,

Thanks for another interesting post on your always entertaining blog. I did have better things to do, you know than start browsing Wikipedia and associated links and learn more about maths and philosophy. No bad thing usually, but I have deadlines I am supposed to be focusing on.

Anyway, some comments for you.

1.
I agree with you that slack, while a very useful thing on software projects has a significant brand problem. So do synonyms like contingency which says ‘we aren’t sure, even though we are experts.’

2.
What can we do about managing uncertainty beyond padding a schedule and budget with slack time? Call upon Wegner’s lemma I hear you say.

But that creates its own challenges which you only partly address in your post. Sure, of course you want a collaborative approach with your development partners, but often the client wants certainty, and is driven not by the desire to do best, but by a fear of doing badly.

(You might find a recent article by our blogger friend Bas de Baar interesting. It addresses this last point at in his recent post about reputations.)

3.
Is your model of contracting systems simply a new term for time and materials (aka ‘cost plus’) contracts?

As always, a pleasure to read your informative blog.

Regards always
Craig

Project Management
Business Analyst

Picture care of Daniel Guip and
Creative Commons at Flickr

Aligning projects with strategy

Executing to strategy is important. Executing non-strategic tasks is wasteful.

Projects are about execution. If you are lucky the project you are working on is aligned to the business strategy. If you are unlucky it isn't.

And if it isn't you should be asking yourself "Why am I doing this?"

After all, when you are done, is anyone going to care?

If you have been reading this site for a while you realise I have a preference for top down planning (and of course, acknowledging the benegits of bottom up analysis into the current state of play.) A top down approach helps you make sure you are staying aligned with the top tier goals of the organisaton.

And of course project professionals need to be able to speak the language of strategy. One tool you might like is a strategy blog I recently discoverred. It's called The Glue and it hs some great insights into strategy from an executon perspective.

Go take a look. I'm sure you'll enjoy it.

• The Glue: A blog about Strategy Execution
  

Project Management
Business Analyst
Photo care of Thomas Hawk and
Creative Commons at Flickr

Punctuated Equilibrium

Remember a few months ago we mentioned Tuckman's 5 stages of team development? Sure you do; forming, storming, norming, performing and adjourning.

Well, here is another view which I think is pretty interesting. It's called Punctuated Equilibrium. (The name is borrowed from evolution theory.)

The basic idea is that about midway through any project type activity the people working on it will see the deadline is suddenly a lot closer and will naturally elevate their productivity.

You can read more on this topic here.

And while we are comparing models, have a look at this one, which overlays the Tuckman's five stages with Gersick's PE models.

The implication for project managers is that a series of smaller, but significant milestones enables project teams to maintain a more elevated performance level over the course of the project than if they are just aiming for the big delivery day at the end of the project.

It's scientific proof of why iterative developments are more effective that one big-bang release.

Project Management
Business Analyst

Project Planning tips

At this time of year there are more than one or two project managers sitting there in front of their project planning/scheduling tool, wondering what's the best way to frame up their plan.

If you are looking for guidance on how to best break down tasks and what deliverable and activities to plan for, take a look at Josh's commentary at ThE pM sTuDeNt.

He provides some really clear and simple ideas that will make your project planning easier.

Here is the post!

Project Management
Business Analyst

Rational Decision Making

And on the topic of justifying decisions rather than rational decision making here is a presentation that explains how pretty much anything can be made to look feasible.

Project Management
Business Analyst

Plans are useless... but planning is indispensable

“I have always found that plans are useless, but planning is indispensable.” - Dwight D. Eisenhower

Studies have found that planning will reduce project budgets by an average of 20% and duration by almost 40%.

Which studies? “Perceptions of Representatives Concerning Project Success and Pre-Project Planning Effort” from 1994. That's around the time of the forst Chaos Report which hilighted the critical rates of failure and mediocrity that IT projects were achiveing.

If you are a fan of a little less planning and a lot more action you might like to take a moment to read this article. I am interested in readers comments.

Project Management
Business Analyst

Urgent/Important Prioritisation

Busy? Always busy? Are you working on the right things right now?

From Stephen R Covey's 7 Habits of Highly Successful People comes this model for prioriting your work:

• Rate what is most important to least important to you
• Then rate these things in terms of urgency. Which ones need to be dealt with no and which ones can wait.
• Place them on ths Grid and now thing again about what work you need to do today, this week, this month.

If this mode of thinking is new to you try this as a weekly activity, until it becomes second nature.

You could also do worse things than buy his book.

Project Management
Business Analyst

Making a Gantt Chart with Excel

Making a gantt chart is a basic technical skill for project managers. It helps you work out who will be doing what and when. It also helps you identify dependencies; for example you need to know your requirements before you design your solutions.

There are plenty of purpose specific tools out there, Microsoft project being the most ubiquitous, but they are also notoriously complex once you start getting into the more advanced features.

I am also a fan of scaling your tools to the project you are on, and of learning the basics of the technique before you defer it to technology. So, in that vein, here is a tutorial I found at Youtube on how to create a project gannt chart in Excel.

Project Management
Business Analyst

Quality Plans

Project Planning is a fairly complex and comprehensive activity.

A project plan is "A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed." (PMI)A quality plan should show

• What specific things will be done,
• Who will do them,
• When or at what milestones or process points they will be done
• What are the relevant quality standards, and finally
• Why this particular quality plan is in place (for context for the users of the plan)

Stakeholder analysis is a critically important task. According to Prosci ensuring stakeholder buy in is one of the top success criteria for projects.

Also knowing what will be done by whom (i.e. in the project plan) clears much uncertainty about the activities that will be done by the project in both the project tam and in the wider audience of stakeholders, customers and suppliers.

Planning takes a more methodical approach to solving problems, and enables the problem solver (i.e. project manager or team) to develop priority tasks, milestones etc as checkpoints along the way to the project’s success.

Steven Covey says that checklists are a fairly unsophisticated method of managing work. Covey puts forward the important/urgent-Quadrant 2 model as a better way to manage time and activities. He also suggests orienting work activities to relationship and outcomes rather than the detailed tasks.

Having thought further I can add some more opinions on what should be in the plan:

• The plan should be focused at things that matter (you have to manage the project overhead and focus on where the most benefit can be found)
• The plan should have specific start and end dates for activities
• The success criteria or quality standards should be specific and measurable
• Quality processes should have owners assigned to them

Quality plans in particular might be thought of as unnecessary overhead; after all they are often referring to things that are already in the project plan or the project process. Articulating the benefits of a quality plan can assist in ensuring that quality is given the right priority in the project.

Often those benefits are the same as normal project planning – the knowing the who, how, when etc to improve accountability and reduce uncertainty.

Project Management
Business Analyst

Project Planning

As I (think I) have mentioned below I am working on an assignment responding to a tender. The assignment's idea is that the planning process in the tender response makes our project team walk through the project management planning activities of:

• Developing a WBS, with dependencies, activity descriptions, etc
• Estimating the time and effort required through scheduling
• Estimating the cost, and determining a price to go to the tender with.

As part of the excesses have put the below process together as a framework to manage the assignment to. It was made in response to the idea that we should start with pricing ourselves according to the market, rather than taking time to understanding our costs first.

In my mind this is the logical sequence in the planning phase. Of course there is a lot more detail and even other activities that can be considered, but given the assignment scope this is a good breakdown of what we need to do.

Allocating Contingency

The last topic for today: Allocation of contingency.

For a while now I have worked on projects where contingency is not allocated at task level, just at the project level. The project leaders and team members have tried to estimate accurately what the effort required will be. The project leader will usually accept reasonable reasons for lateness including lack of experience and incorrect estimates.

The overrun is then taken from the overall project contingency (which should have been factored to include the teamÂ’s experience and any other risk issues.) This strikes me as better than everyone adding contingency at task level, then more contingency at a work-stream level, then more again at the project level.

Previously we had a discussion of who pays for changes - and us IT workers tended to charge all changes to the business unit that requests them, while construction people tend to manage it according to the scale of the change - often taking the change costs out of the contingency.

Other views on contingency management:

• Allocatecontingencyy against specific risks - US Dept of Transport, AHDS in the UK
• Allocatecontingencyy against work items, butbasee them on historical records - this is the usual approach in construction
• Pad out tasks to include additional review steps
• Building in to the project

Overcoming Microsoft Project - Resource Allocation

Microsoft Project always sucks when you want to look at your team's resource loading over the project. The histogram in MS Project doesn't give a good, scaled view of the team over time.

In a lecture I was at last night Michael showed a simpl and obvious tip; he simply cut and pasted data from project's Resource Usage screen to excel and then simply created a histogram.

An obvious solution, but one I had never thought of.

Development methods and Estimating

And yet more on Resource Allocation and Management.

As mentioned below many estimates are made from asking experts and specialists or past experience. In class we had a discussion on the impact of using historical experiences for estimating effort on IT waterfall projects, which are heavy on planning and estimating. The issue was raised that if our programmer estimates 5 days to complete a piece of work to specifications and he completes in 2 days the extra three days are not given back to the project, but used to improve the quality of the work, often beyond the requirements.

Rapid Application Development was discussed as a concept that can alleviate this issue to a degree. Several iterations of the solution are developed until the appropriate time, cost and quality balance is achieved. I think Agile methods are probably a better model for addressing this soaking up of excess time, as the developer and businessperson are more closely aligned in their view of what needs to be done.

There is probably an opportunity for someone to do some research in this space. Or if some has been done for someone to tell em about it :)

I'm still loving wikipedia