Search This Blog

30 October 2009

How to organise a Children's Party

This will probably spread like wildfire in the pm/agile blogging community. May as well get on the bandwagon!

29 October 2009

Building agile project management capability

This prezi is by Matt Hodgson who i have been showcasing here a bit recently.  I like his presentatoions.  What can I say?

This one does a good job of showing a path to agile practices for conservative and bureacratic organsiations..

28 October 2009

Management and leadership

Do projects need leaders more than managers?

Here is a definition of management

Management is the process of achieving organizational goals through engaging in the four major functions of planning, organizing, leading and controlling (Bartol & Martin, 1998 in Management).

Here is a definition of leadership (in the enterprise context.)

The process of influencing others to achieve organizational goals (Bartol & Martin, 1998).

Are they mutually exclusive things? Can you lead without management? Can you manage people without leadership?

To be an effective leader you need to have some semblance of organisation. You need to be able to plan your work, understand the outcomes you are trying to achieve lead and motivate others on the way and clear impediments out of the way.

In enterprise project management you need to be able to manage stakeholders, and manage people through a project’s processes. You need to be organised to manage the complexity that comes with the territory. If you aren’t organised you won’t get the respect and trust you need to lead people.

To be an effective manager of people, either reports or stakeholders, you need to be able to lead. Leadership is not technical expertise, and it isn’t having a vision for the product. Leadership is engendering trust in your decisions and confidence in your ability to get things done. Leadership is part of management.

Management without leadership is poor management. Leadership without management is movement seeking a purpose.

The thing is that leadership and management aren’t binary attributes. It isn’t as if you either have it or you don’t. Both of these skills grow as you study and practice them. Actively seeking feedback and reflection speeds up that growth.

So, yes there are some people who are way off the mark, but most, even many of us have great potential.

I was listening to part of a Noam Chomsky interview the other day and he said something like ‘…corporations aren’t run by bad people, they are run by smart people optimising bad systems.’

Maybe a lack of forethought and a lack of big picture thinking is the problem. This thinking falls into the management role of planning, doesn’t it?

And if you need to break out of your current system? That takes leadership.

21 October 2009

Ethical dillemas for Analysts

1.  Here is a question at BATimes (login required) about what you would do if you felt a project was urposely delivering a product that would;

Be functionally worse that the legacy system it replace, and
Potentuially brach accounting or other regulatory rules.

What would you do? Click through and offer an opinion.

2.  Amanda Becker provides three real life ethical dillemas at BNet and asks you to say how you would handle it.  You get to compare your results to others, and to what really happenned. 

Ethics are harder in practice than in theory and the best ways to arm yourself for tough decicions are to practice your ethics in safe scenarios *such as role plays or surveys) and to know your moral compass.

While we are on the topic, have a look at Caveman's flickr page (The source of this post's picture) where he describes the US Office of Giovernment Ethics (and browse the comments while here.

20 October 2009

Managing your Steering Committee

Tim van Gelder writes a post on how boards use information and make decisions.

Two key pieces of information that I took away from the post are that Boards will share better if they think they are solving some kind of factual issue as opposed to making a judgement requiring consensus.

Boards share information better if they use a structured discussion process, rather than just indulging in the usual kind of spontaneous conversation.

The idea here is that Boards need to be actively engaged in managing things. For me and you it is our project steering committees and governance groups. How do we get them more involved in the project?

By making board members participate in certain decisions they 'own' the solution more than if they just front up and rubber stamp a progress report.

Every report on project success or failure includes mention of close customer engagement as a key success factor. Frontline managers are not the customer. The sponsor and steering committees are much better embodiments of the customer, as they are the ones paying for the product your project is delivering. Getting your board members involved is a step in the right direction.

In order to help boards collaborate more, Tim endorses a McKinsey recommendation to augment proposals and recommendations with a 'red report' or the counter argument to the actual recommendation.

This is a common approach used in project management: the infamous 'three options' including or augmented with the "do nothing" option. Depending on the time and relationship you have with your board/sponsor, and the importance of your project what can you do to get them more involved in your next board (or steering committee) meeting?

Picture by mugley CC@ Flickr

18 October 2009

UAT is going well

iTWire reports a dozen common or critical failure modes for an agile implementation, lifted from Agile Australia 2009.  It's interesting to see the angle mainstream IT press in Australia has on this theme. 

The last point in the article is one close to my heart.  Falling back to traditional appproaches when it all gets too hard.  As the agile point man at my current engagement, I definitely know that feeling.

On the other hand, we ran our second round of UAT last week and in both it and the first round we only came across one bug of moderate significance.  This is a pretty fantastic result, especially from a team who's previous release didn't even run on day one of UAT, and that's not even considering the huge schedule differences.

It seems a process that enables, rather than tries to force particular agendas can really make a difference.  Once the product is more mature we might see if we can turn out a white paper on the topic.

17 October 2009

"Never give a fool sterile information, because he cannot ignore it."

"Never give a fool sterile information, because he cannot ignore it."

So says Nasim Taleb when discussing risk management in the financial industry. 

The same can be said about our industry.  Think about this paraphrased comment; If we all use the same risk management framework, but we price risk wrong, we are headed for a huge problem.

So, when you are assessing likelihood and impact you are assessing the cost of things going wrong.  But are you thinking about the work that is required to manage your risk?  Do you update your schedule and budget to acknowledge additional effort required to manage these risks?

There are two things going on here: Being transparent and accountable about the cost of managing risk and building resilience into your project.

15 October 2009

Co-location of teams

Adrian at the Scrum Development message group handed out a list of resources for justifying co-location of teams.  It covers international and intra-building co-location.

Your instincts tell you that this model is right.  Broader bands of communication help get things done.

People working close to each other over-hear conversations and chip in with their experiences and opinions.

Us and Them divides are conquered.

One space per team...

The list is good.  Check it out.

13 October 2009

Planning and Patterns

Planning is one way to anticipate the work you'll need to do.  Patterns are another.

Plan for when the work is new, unknown and unique.  Patterns are for common problems.

Some patterns and plans are also presented as processes.  I'll leave the idea of work as a process to you and the comments below.

If you know the work you'll need to do well and intimately ahead of time, it's a pattern.  We find patterns all over the place in project management, especially in strongly process oriented organisations.  Here are a few examples;
  • User acceptance testing pattern; You set up a replica of your production environment, write up test cases around the system capabilities, execute the tests an report on the outcomes.  All good?  Go live.
  • COTS Product evaluations pattern; Define your needs, investigate options, compare, select.
  • Scrum pattern; Plan a sprint, execute, demonstrate the outcomes, reflect.  Repeat.
At a higher and lower level a pattern can be surrounded by or embedded with more patterns or with planned work.

Scrum for example is a pattern.  The details within the sprint need to be planned (hence it kicks off with a planning session.)  Some of those details may also be patterns.  For example, in my team the QA process is a pattern within the sprint that is repeated several times.

So, if you know the activities you'll need to do, it's a pattern. Patterns save time and bring consistency.

So, as I said above, that leaves plans for the uncertain, untried and unique work.  Something implicit in this statement is that plans have to accomodate uncertainty, and allow for details to emerge as you travel with them into the future.

Plans are important because they help you think ahead though the uncertainty and complexity.  Plan's don't have to get you to the right answer every time.  Their  job is mainly to help you anticipate some of that uncertainty.

Projects, at least the ones I have seen, use both patterns and plans to organise the work.

Both planning and patterns require something to make them work; good judgement.

When should you use a plan and when should you follow a pattern?  When do you customise a pattern and when do you populate  plans with patterns?  You need to think about these things, and that part of the organising process is planning.

Picture by Lachlan Hardy, CC @ Flickr

12 October 2009

Tinkering with the site design

Hi people,  If you've clicked through to the site from your RSS or emails, you might have seen me tinkering with the site design.  Feel very free to tell me what works and what doesn't.

11 October 2009

The A word

This is a short video introducing the idea of 'agile projects.' Light hearted and entertaining.

9 October 2009

Notes on a data migration

When preparing to test a data migration we wanted to know how many records needed to be inspected. I googled for a calculator and this site came up.

Let me give a hypothetical scenario to illustrate how it can work for you.

I have a 1000 accounts of VIPs being migrated from a legacy system to a new online travel management tool.

We want to migrate their current details including name, company, address, contact details etc. We are also interested in migrating past travel details, but this will be deferred to a later release.

The VIPs are important customers to us and we have no tolerance for mistakes. By no tolerance I mean that if a handful of them has a problem, I can handle it, but not more because, as I said, they are all VIPs. So no tolerance means 1% room for error.

The developer work has been unit tested and peer reviewed and it looks like the data is in pretty good shape in the legacy system, so I only need a 90% confidence level on the test.

(This stands in contrast to our 85% unit test coverage, 0% automated UI tests, and 75% coverage of cases in UAT.)

We also do a pre-test check in the developer environment and inspect 20 records and find that there are three mistakes, so we add in a response bias of 15% (which is 3/20.)

The calculator tells me that out of 1000 cases I need to test 122 records. With an error tolerance of 5%, a confidence level of 90% and a bias of 15%.

That scenario includes the potential for up to 50 VIPs to encounter a problem sometime, based on the data we migrate. Maybe that’s one a week in the year, or maybe, because they are VIPs and travel a hell of a lot, it’s 50 in the first month. And we know that each problem costs us $300. The potential for errors at this threshold is $15,000, which is about equivalent to 3 weeks of testing time.

So we know that the potential cost here outweighs the cost of some additional tests. If we target an error tolerance of 1% we need to run 776 tests. Each test takes 10 minutes, so that’s about four weeks worth of testing/inspecting effort. That’s a bit too expensive, so we start exploring the numbers in between until we find the right balance between risk and cost.

Okay, I am no stats expert and would love some commentary on this scenario.

8 October 2009

Project success requires sales

Melissa Raffoni gives us “Eight Questions to Assess Your Sales Organization.” She is discussing sales in the context of CEOs and their organizational priorities.

When you look at a project team it, too, is an organization with suppliers, customers and stakeholders. So these prompts for CEOs might be useful for the project leadership community.

I’ve lifted Melissa’s questions and offered my own thoughts on each topic. I’d love to hear your thoughts.

"Ok, tell us again, what's your value proposition? Why should customers choose you over the competitors?"

Who and what are your competitors?

Firstly there is the option to simply not run the project and instead invest into another problem or opportunity. Ask yourself where your project sits against the strategic goals of your organization. If you can’t draw a straight line to a significant value proposition you need to be asking yourself whether the project is really viable.

Secondly, will other projects and business priorities cause you problems? Will you have trouble hiring people, and buying the tools and equipment you need? Will you have the right people for the job?

Thirdly, why are you building a software solution? Can the product be bought? If so, what has made you decide to start from scratch with all the costs and delays this entails?

"What is your sales process and how does your organizational structure map to it?"

The sales process is one of listening and mapping value back to your capability, and helping your customer make the decision that the value proposition you offer is the right one for them.

Stop and think about that for a moment.

Now think about your requirements management process.

Is requirements management sales? Does it incorporate sales? Do your requirements people think (know) they are in the sales business? Do they have the skills to do this work?

If you have a requirements management plan, how does it map to a structured sales process?

"Do you think your overall cost of sales is where it should be? What makes you think that? Are you comparing to an industry standard or mapping to a projected financial model?"

Back to requirements management. What portion of the project budget is allocated to requirements management? What portion of that work is allocated to the sales part of the job?

Does this feel right to you? Do you need to put more in? Or less?

“What key measures are you using to track sales effectiveness? Do you have a sales dashboard?"

In the enterprise project space this sounds like tracking stakeholder satisfaction. How do you measure this? I know many of you are tracking stakeholder engagement, but does engagement matter as much as satisfaction?

And what is the right thing to measure? Working software is a good option. Prototypes are another. But if you can’t quickly get to something tangible, what are your alternatives? Are they good options or bad ones?

"If you believe there are two ways to drive sales--increase the funnel and/or increase the close ratio--what are you doing to achieve those increases?"

For me this question asks me about the front and back phases of a project. Are we shooting for many diverse benefits in the business case, or focusing on just one or two main goals? Are we delivering on our targets once we get to the end of a project?

"Is sales compensation driving the right behaviors?"

Rewards in the enterprise are a tough thing. The HR structures appear to be removed from line management with the express purpose of blocking rewards for good work. (Is it just me here people?)

So without addressing money, are we rewarding the right things?

Defining what Success is for projects is slippery enough. How do I optimize the measures I use to get the best out of my team?

"It's a new world, how are you taking advantage of it?”

New world = new technology + new modes of interaction.

Modern project management, requirements management and software development tools add a lot to our capability. Even more important are the industry lessons that have been learned and shared via blogs, forums, newsletters, podcasts and other media. You don’t have to repeat the mistakes of others.

What have you learned about your trade in recent months?

“Do you have the right people?”
Every investigation into project success and failure highlights the importance of people. Projects are impossible without good people. But no-one is perfect, nobody is always at the top of their game, and not everybody is an experienced and motivated expert.

So I have two questions;
  • What can you do to make your team perform to the best of their abilities?
  • Are you checking with your people before you make promises about schedule, scope and costs?

With that I leave you to reflect and maybe book yourself on to a sales training course. Let me know your thoughts.

Picture from Wisconsin Historical Society CC at Flickr here

6 October 2009

Perks’ 1st Law of IT Integration

This was new to me;

Perks’ 1st Law of IT Integration:

IT components that are not designed to fit together and form a working system only do fit together by chance.

I found it in a slide deck called The sins of IT projects and why they fail (some times) by Maurice Perks.  It has an accompanying video also.

It also has this quote by Charles Darwin;

It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change 
Picture by law_keven, cc at flickr

4 October 2009

Sustainability (aka Green) Requirements

I posted a question at Modern Analyst; What sort of Sustainability Requirements are people writing? Curious? Go see what people have written.

What about you? How do you include envirnmental issues into your project?

Greening your project is actually harer that you supose it will be on first reflection.  There is a cost/benefit trade-off here. Spend money now to save later.

One thing you should do is check your company's environmental and CSR policies to see how you can roll in sustainable requirements as development constraints.

If you want to take the conversation further, please do here, there and other places.  The more the better.  This is a serious and ugent issue.

Picture cc by Powerhouse Museum at Flickr

3 October 2009

Social Media, technology projects and the enterprise

Today the Australian Information Architect's conference kicks off. One of the speakers is the guy who told me about it, Matt Hodgson.

He's an IA and spends a good deal of his time consulting to Australian governement on how to loosen up, technology wise.

Here are some of the diagrams he talks to when discussion web 2.0, social media, and stuff..

2 October 2009

I finally finished The Drunkards Walk

I finally finished The Drunkard's Walk. That's not to say it was a hard read, just that I am finding it hard to get leisure reading time.

This book, by Leonard Mlodinow, is on probability. It was comforting to see that I knew - or at least was familiar with - most of the theories discussed in the book. It was interesting to read the history of probability, statistics and uncertainty presented in an entertaining and conversational style. (I remember ending the statistics class in my undergraduate degree knowing less coming out than going in.)

I would recommend this book to anyone interested in the subjects of uncertainty and probability. It isn’t a ‘how to’ book but it has plenty of anecdotes about estimates gone wrong which you will probably find interesting and amusing. It’s a nice introductory book coming at ideas from a regular human perspective. If you seek more on the topic you can go search.

Got a long weekend or a holiday coming up?  Grab a copy.  You'll like it.