Better Projects

Friday

2009-11-05T23:47:00.000+11:00

This Friday is a busy day for me. In the meantime, take a look at this.

Contracting versus Full time

2009-11-04T09:00:00.002+11:00

Alister Scott provides a simple little calcultion showing comparable full time and contract rates. He compares an $80kpa full timer to a $60ph contractor and finds they earn about the same.

If you are interested in exploring contracting this explanation may help you understand that the benefits of contracting are not all financial, and that the differences in what contractors get paid is not as large as some people assume.

Read more here.

What _do_ we need from our professional organisations?

2009-11-04T00:06:00.001+11:00

Matt Hodgson worries about about the BA community repeating the mistakes of the project management community by taking a narrow definition of the role and formalising it. Embedding itself in a position from which it will be challenged to evolve.

His questions wrap around the ideas of community, discipline and roles.

If you are interested in the ongoing formalisation of the BA (and PM) roles and are wondering/worried about the directions they are headed, read his post and offer your comments.

Capability is as important as Customer

2009-11-03T09:00:00.001+11:00

There’s a lot of talk about outside in thinking and design , and about transformation driven by customer problems. And this talk tends to disparage the approach of “look[ing] around at their capabilities and try[ing] to figure out how to fit them onto the market.”

This strikes me as the pendulum swinging too far the other way.

Yes, a sales driven approach to doing business is insufficient. But no, exclusively adopting a customer centric approach to business growth is equally silly.

Back in Marketing for Projects 101 we talked about marketing being a process of creating value for both the producer and the customer. Think about a simple, two circle Venn Diagram with the circles overlapping.

A market driven approach means building value for both the organisation and the customer. And this means that you need to understand both your customer’s needs and problems, and your own capabilities.

A simple example highlighting the capabilities point is Amazon.

Book publisher? Yep.
Cloud service provider? Yep.

Did you see that second one coming a few years back?

If Amazon had just focused on their customers (let’s say book buyers) how would they have spotted the great cloud utility opportunity in front of them?

The same goes for project teams and sponsoring organisations. Understand your customer’s needs and problems, but also understand the team and sponsoring organisation’s capabilities.

Know yourself.

Photo shared via cc at Flickr by sylvar

The MBA Oath

2009-11-01T09:00:00.014+11:00

You may have heard of a Harvard University initiative to get MBAs to sign up to an oath on responsible value creation. I found it via Mike Clayton's blog.

Here it is;

THE MBA OATH

As a manager, my purpose is to serve the greater good by bringing people and resources together to create value that no single individual can create alone. Therefore I will seek a course that enhances the value my enterprise can create for society over the long term. I recognize my decisions can have far-reaching consequences that affect the well-being of individuals inside and outside my enterprise, today and in the future. As I reconcile the interests of different constituencies, I will face choices that are not easy for me and others.

Therefore I promise:

I will act with utmost integrity and pursue my work in an ethical manner.

I will safeguard the interests of my shareholders, co-workers, customers and the society in which we operate.

I will manage my enterprise in good faith, guarding against decisions and behavior that advance my own narrow ambitions but harm the enterprise and the societies it serves.

I will understand and uphold, both in letter and in spirit, the laws and contracts governing my own conduct and that of my enterprise.

I will take responsibility for my actions, and I will represent the performance and risks of my enterprise accurately and honestly.

I will develop both myself and other managers under my supervision so that the profession continues to grow and contribute to the well-being of society.

I will strive to create sustainable economic, social, and environmental prosperity worldwide.

I will be accountable to my peers and they will be accountable to me for living by this oath.

This oath I make freely, and upon my honor.

So, what do you think?

I think it's a nice initiative, but you shouldn't be betting your house on a shift in ethical behaviour by the people who sign on.

As a sceptic, I presume this initiative is more PR than anything else.

On the one hand, this voluntary oath is likely to attract people who are going to act relatively ethically anyway. On the other hand, how's the hippocratic oath doing these days? Is it working for you?

On the third hand it does make people at least think about the issues they are going to face when dealing with real business challenges. And we do know that mentally rehersing something can at least partialy prepare you for the real deal of ethical dilemmas.

Back to Mike Clayton. He's made a call out for project managers to draft their own oahs and publically call them out. I'm pretty comfortable with my values and so I think I'll stand by my actions rather than sign on to a list.

But what about you?

I am particulary interested in hearing how you'd prioritise conflicts between "shareholders, co-workers, customers and the society in which we operate."

Who wins in a tussle between shareholders, customers anc the community?

How to organise a Children's Party

2009-10-30T09:00:00.003+11:00

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

Building agile project management capability

2009-10-29T09:00:00.002+11:00

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..

Management and leadership

2009-10-28T17:16:00.000+11:00

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.

Ethical dillemas for Analysts

2009-10-21T21:47:00.001+11:00

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.

Managing your Steering Committee

2009-10-20T09:00:00.000+11:00

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

UAT is going well

2009-10-18T17:47:00.000+11:00

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.

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

2009-10-17T09:01:00.000+11:00

"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.

Co-location of teams

2009-10-15T13:00:00.000+11:00

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.

Planning and Patterns

2009-10-13T08:45:00.013+11:00

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

Tinkering with the site design

2009-10-12T22:45:00.001+11:00

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.

The A word

2009-10-11T09:00:00.004+11:00

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

Project success requires sales

2009-10-08T09:00:00.007+11:00

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

Perks’ 1st Law of IT Integration

2009-10-06T06:00:00.000+11:00

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

Sustainability (aka Green) Requirements

2009-10-04T09:00:00.021+11:00

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

Social Media, technology projects and the enterprise

2009-10-03T08:00:00.004+10:00

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..

I finally finished The Drunkards Walk

2009-10-02T09:00:00.004+10:00

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.

The Drunkard's Walk (Amazon)

As a project manager

2009-09-30T05:00:00.011+10:00

As a project manager my job involves two main responsibilities;

Providing an environment condusive for the team to do their best work
Keep the client informed about progress, specifically addressing expected budget schedule and scope.

As a project team member - or customer - does anything else stand out as important?

Pic by Photomish Dan, CC at Flickr

Another BA Competency framework

2009-09-29T09:00:00.001+10:00

Carrying on from Ambler’s essay on Agile Business Analysts; I want to throw up Scott’s list of “Do’s and Don’ts” for business analysts as a potential for a competency framework.

Why?

There is a discussion going on at Linkedin (It's the Modern Analyst Group) about BA Competency frameworks and, well, heck, why not offer another point of view.

How?

Take a look at the list of positive contributions and assess yourself or your BA team members on a scale of 1-5, then take a look at the negative contributions and score from 1-5 again.

This model is derived in part from Frederick Herzberg’s Hygene theory of management and Kano requirements analysis which acknowledge that there are both potential positive and negative outcomes of things such as management and features.

Positive contributions

Scope the system
Translate business needs
Translate technical issues
Model and document
Act as a communication broker
Political mentor
Test and validation
Represent stakeholders

Negative contributions

BAs often lack the right skills
BAs can have undue project influence
BAs can be out of date
BAs can act as a communication barrier
BAs can reduce stakeholder influence
BAs often over analyse
BAs can reduce feedback
BAs can reduce opportunities for developers to gain communication skills

Some of these terms need some filling in. An example; “BSAs often lack the right skills.” What are the right skills? What is their purpose? What is their context? What important outcomes will this lack of skills affect?

For Scott’s definition you can go to his article. You can also make up your own to suit your context. Remember that the context is the important think. For example, UML doesn’t matter as much as the ability to effectively get their product vision across to developers and stakeholders.

Rethinking the role of a BA on Agile projects

2009-09-28T09:00:00.002+10:00

Scott Ambler has a pretty solid library of tools and techniques on all sorts of agile practices. One particular essay he has written is on “Rethinking the role of the Business Analyst; Towards Agile Analysts?”

I read Scott’s basic view on the topic as two main points;

Analysis is critical to project success, analysts are not, and
The right degree of up front analysis is not none, but it is not as much as people expect

I buy both these propositions.

Scott has a third position;

The role of the BA is to overcome barriers such as competency and time

In his essay Scott calls the BA a “Band Aid” – highlighting the role as a patch for a more deeply ingrained problem.

I don’t buy that one. While he has some valid points, the BA in an enterprise also plays a legitimate & important role in balancing competing priorities. Scott will say that this is the role of a project sponsor, but in truth senior managers have to delegate.

A BA may – can – and in many cases – should - act as a product owner or sponsor/customer advocate. It’s a natural evolution of many Business Analysts roles.

This adoption of responsibility can be done with or without adopting agile processes and practices. It’s about taking responsibility for project/product outcomes and working with the team on achieving them.

Information architects are like Robin Hood

2009-09-27T12:31:00.004+10:00

"We may look like pansies..."

You can see more of this at the OZIA conference in Sydney Fridat and Saturday this week.