31 July 2008
29 July 2008
Many are overly optimistic. Some are overly pessimistic. Most are full of educated guesses (and some are not so educated.) Many are trying to justify the project on only financial value statements.
Let's start with first principles.
Projects should deliver value to the clients. That value can come in financial and non-financial ways.
If the project is aligned with strategic imperatives then it is probably a better use of resources than a project that isn't contributing to strategy.
But you also have to balance capability with desire, so some projects do end up being about quick wins and what we can do, rather than what we should do. This is managed through a project portfolio approach.
So now I am getting to the trigger for this post. I was browsing Scott Quick's website and found this quote from Forrester;
- "Successful packaged apps strategies require business process and applications professionals to align with corporate business drivers. But because business drivers for individual IT projects often shift with time, the portfolio of apps initiatives requires organization and alignment by economic state and project risk. Once alignment is achieved, business process and applications professionals should identify the high-priority initiatives that best align with current business drivers and create a business technology (BT) value plan that connects the dots between corporate strategy and application tactics."
Sounds sensible to me.
The agile software development crowd have a solution for this - it's Scrum's product backlog and short delivery cycles. But you don't have to use agile methods to address this issue.
Everybody is familiar with prioritising requirements and there are dozens of models to help you do this. The problem is that many people get caught up in the optimum solution versus the bare-bones delivery paradigm.
It doesn't have to be one or the other. It does end up that way if you don't prioritise your work properly though.
Each requirement line item has to be mapped back to the business strategy, and it must be clear about what the value it brings.
My personal bias is that I feel requirements often get convoluted and very detailed and so lose their relevance to business strategy and goals. So for me, another important issue is in maintaining simplicity and clarity of your message along the project value chain.
So, how about it requirements managers, can you do that with the set you are working with today? And if not, what needs to be done to improve things?
Maybe the thing we need to include in all our project documentation is a value management plan?
28 July 2008
Six Sigma may be on the back of the hype curve by now, but there is still plenty of value to be found in the model. If you don't know much about it, and are curious - here is a slide presentation that gives a good quick oveview of the key concepts.
27 July 2008
Here are a couple of snapshots from the original in 1994 and more recently 2002.
So what is this improvement due to? If you have a look at the issues reported as failure and success criteria over the life of this report you see there are a number of key things that changed - most prominently the professional (usually PMI or PRINCE2) training and experience of the project manager. The second key issues that seems to have contributed to this imrprovement is sponsor engagement and support.
The thing is - this improvement is just incremental. There is plenty of further opportunities ahead for us.
Examples include shrinking the size of projects to something that is manageable, and making sure requirements are properly managed right through the project lifecycle.
The Agile Alliance and the IIBA are taking steps to move the industry in these directions. What else can be done?
More particularly, what are you doing?
25 July 2008
24 July 2008
At the top level you have three options;
1. Quit and go work somewhere less chaotic,
2. Step in and be guided by the people and procsses already in play, and
3. Put aside the day to day busy work and address the key problems.
Let's presume you pick option 3.
I've written about this in the past and my opinion remains the same; the thing to do when you join a project - where the wheels are spinning but nobody's moving - is to start with risk management.
Basically the project risk management framework puts a structure in place for you to identify risks to the project (particularly time, budget and scope) and to get people to help you tackle them. Especially your sponsor and steering committees.
It works because it is structured and formal and makes the people around you accountable for doing the right thing, rather than just what they were planning to do. It's also a good way to zero in on the critical items that are not urgent but are lurking around the corner - and need to be tackled.
That's the strategy, but in some places it's hard to find the time to deploy it.
So four more suggestions;
1. Get help.
Pick someone in your team and enlist them in your risk management mission. They do the paperwork and organise meetings. You do the leading, motivating and investigating to help get things moving along.
2. Don't be afraid to put other things aside.
There is often scope to drop administrative tasks such as weekly reports, meetings with team members or non critical stakehodlers. Think about whether meeting with these popel is substantially contributing to your project's goals or is just taking up yor time. Delegate or cancel. You have more important things to do.
3. Force a rhythm.
If your team are busy but not focused, and if the same applies to you, a quick way of getting things structured enough to give you breating room is to set a rhythm to your teams work. Pay attention to the natual rhythm of the project and organisation and set your cycle of events to match that. Make one of your regular events the risk management activities.
4. Don't sweat lost time
Often people are scambling to meet missed milestones. They'll never recover. Better to admit the slippage and focus on regaining control. Otherwise you'll just keep spinning those wheels in the sand.
Anyone else got ideas?
23 July 2008
These are the skills that set up a student in their early years so thyey are better equipped for learning in the mid and latter years. Typically numeracy, literacy and problems solving fit into this set.
It got me to wonderring what the enabling skills are in our profession. What do you need to know first in able to set yourself up to continue to grow and improve in your role?
I suspect it's not the obvious candidates.
Dear readers - I'd love your comments on this one.
19 July 2008
Here are some of the best articles I found this month.
If you want to advance in your career, you need to make sure that both your online networking efforts and your overall Web presence are working for -- not against -- you.
Hard lessons from the coalface…
Open Source and the War for Talent
- how the opportunity to work on open source projects helps attract top talent.
Not all IT jobs are being offshored and outsourced. Some positions in IT are among the most recession-proof jobs across all fields.
18 July 2008
Around here we like to think of project professionals as a service industry people – you’ve been hired to provide your professional services to delivery a high quality project.
The sponsor was hired to do a job also – and they have a service obligation to you. Well, they probably weren't hired to specifically be a project sposnor, but they were hired to solve business problems and one of the tools they have picked is your project.
You already know some of the sponsor's role by rote; they provide strategic goals & measures of success, and the clear obstacles & provide an escalation point within the organisation
But a default job description always needs customising.
If you were writing a job description for your sponsor, what would it say? And how would you measure their performance? And how is your existing sponsor going?
Do they need a hand?
16 July 2008
Lore of Wizards is a collection of stories from senior consultants. Chapter by chapter a book is being released online. The latest chapter (4) is Managing Client Relationships. Previous chapters are "How We Got Started", "What it Takes to Succeed" and "Dealing with Clients." You can access them here.
What I really like; the variety of stories from the elder statesmen of our industry. Wisdom. Simple messages. Not trying to sell you something.
The writing is simple and lovely. The stories range across many perspectives and topics, clustered by the chapter themes. Here is an excerpt to tease you into clicking through and reading it yourself.
So I took the extra thousand.
I worked in my dad’s business after I got out of school, followed by a stint in the Navy. I had an accounting degree and really wanted to be an auditor. In 1968, a friend of mine, a fraternity brother, called and suggested I try to interview with Arthur Andersen. I did and was very impressed with their approach. I liked their attention to people and professional development. I hadn’t really seen anything like it before. They also said they would pay me $11,000 to be an auditor or $12,000 to be a consultant. I had a wife, one child and another in the oven so I took the extra thousand. And that's how I became a consultant.
Taking the job meant moving to New York from Pennsylvania where I was then working. We didn't have any money and my wife was very pregnant and I had rented this apartment in New Jersey for $190 a month. It was a very small two bedroom with a leaky roof. We had two women of ill repute living below us who entertained people at all hours of the night. The first time my wife saw the place she cried. But it was the only place we could afford and we lived there for three years.
I’d been working in factories and had ripped all the pants for my suits. So I had no suits, just sport jackets and slacks. Of course, you had to wear a suit at Andersen, so we scraped together all the money we had and I bought myself a suit. On the very first day of work, it rained. I mean it rained big time. And I had to wear that suit every day for two weeks, until I got paid and could buy another one. My wife ironed it every night for two weeks.
People like me, that's who. But why? Could it be a desire for stress? A need to stay back and work late regualrly? The love of paperwork?
I wish I knew. Maybe it's a combination of timing and the desire to test your skills. Maybe it's just dumb luck.
PMHut re-publishes (with permission) many blog posts on project management. If you want to look up a concept or idea - go there and use the search tools. If you want to keep abrest of what many project management bloggers are writing about, subscribe to the site.
Well, maybe it was really 4/5.
If you want to know what sort of project I have walked into recently - take a look at this post by Thomas K Casey. (It explains this post's title.)
15 July 2008
14 July 2008
The Black Swan: The Impact of the Highly Improbable
by Nassim Nicholas Taleb
This book is definitely a useful read for anyone who has a job where they need to plan for the unexpected. This is a look at statistics and how they can fool people into believing they can safely predict future occurrences. Mr. Taleb takes examples from science and finance like the titular discover of the black swan in the 17th century and the stock market collapse in 1987 and delves into why they were not predictable.
From a business analysis and project management perspective, this book is an excellent way to get you started thinking about risks and risk management. It reminds you that past performance is not necessarily an indicator of future performance. It also explains why statistics are not sufficient for fully predicting possible risks.
For me, this book got me thinking about the unexpected occurrences that can ruin a project. You can only plan for as much as you know. There is always a risk of a Black Swan showing up to throw a monkey-wrench into your project and somehow you have to account for that possibility.
13 July 2008
The project shrink idea you articulate reminds me on an ‘executive coach.’ For quite a few years now senior managers and middle managers with aspirations have been booking these coaches to help them reflect, learn and improve their performance. And of course there is the sporting analogy.
So let me see. A person is engaged by a project manager on a part time basis to help the project manager see above the day to day drams and look at the big picture. By helping we don’t mean doing, so deep expertise in project management would not be a mandatory skill set, but some experience wouldn’t hurt. A few war stories of your own help you understand your client and help you raise awareness of particular risks.
Now, this is a role which could be fulfilled within a number of other roles including a project manager’ direct supervisor, by a more senior colleague, or by someone from outside the organisation. Potentially it could also be played by a project sponsor. The trick is in understanding the need and prioritising time (and money) to the activity.
I buy the role is a useful one, especially as projects grow larger and more complex.
Selling the idea to my management is another thing though. They expect me to be an expert when I turn up to my first meeting. In some cases I am the one bringing pm expertise to the environment, so it’s all about levels or layers of pm maturity.
Let me ask you this Bas; Are you using a project shrink? And if not, what do you need to enable the role for you and your projects?
Bas and Craig have a weekly conversation, back and forth on their respective blogs, Project Shrink and Better Projects. With blog titles like that, you don't have to guess what the topic will be.
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?
12 July 2008
You can read the blog here - plenty of good stuff - which I intend to talk about in coming posts.
But before I do... the bug.
Graham's site introduces this little bug with the below content. (Which saves me the effort of explaining.)
Matthieu Latapy is a network researcher at the National Centre for Scientific Research (Centre National de la Recherche Scientifique) in France. He is doing network research to counter peer-to-peer paedophile content - something I think we would all agree is very worthwhile!So, friendly bloggers - your turn.
Matthieu is conducting an experiment aimed at understanding how a real-world spreading phenomenon occurs via links between websites. In particular he notes that information diffusion is increasingly orchestrated by bloggers instead of the mainstream media. Matthieu's experiment takes the form of a viral marketing approach - hence the name Happy Flu.
To participate all you need to do is:
The image you see is the diffusion path of the code, which should change as it spreads.
- click "spread it" on the image above,
- enter your url,
- copy the code that will put the image onto your website, and
- create a blog entry and paste the code into that entry.
Go on - help Matthieu and spread the Happy Flu. Any research and experiment that combats paedophile content must matter!
11 July 2008
And PM processes are gernally described as initiating, planning, executing, monitoring, controlling and closing.
See the similarities? See the differences? What makes projects special?
Where does leadership fit in to the picture?
10 July 2008
“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%)
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
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.
In thinking about this issue I have created a model that divides a project into the dimensions of the business requirements (ie processes) and the solution (ie technology.)
These two dimensions frame how familar or unfamilar your stakeholders are with how your project is going to go about it's business. And this familiarity will drive particular behaviours and risks.
For example, if you are using new technology and addressing new business processes you have an opportunity to be quite innovative as you don't have as many constraints as (many) other projects do. Take advantage of this.
If, on the other hand you are dealing with existing processes and will be using existing technology infrastrcuture to solve the problem you face many constraints. On the other hand, everybody knows the territory, so you should be able to work through design, development and validation activiteis quicker than in other cases.
Where does your existing project fit, and how does this drive design decicions, and project management processes?
9 July 2008
But I need to be able to explain it to people.
I can explain this; NPV is a way of assessing differet projects over different time periods. It helps pick and choose what goes into your project portfolio. It helps understand whether the project meets the opportunity cost thresholds your organisation has set.
And the calculations themselevs are easy enough once you know how to use the excel NPV feature.
But explaining it still stumps me. This is me having a go.
Someone - Help me out and do a better job.
8 July 2008
As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative.
This requires considerable tolerance.
Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.
Mistakes will be made.
But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.
Management that is destructively critical when mistakes are made kills initiative.
And it's essential that we have many people with initiative if we are to continue to grow.
(Read about him here.)
I post this because in many projects and in many organisations the game is set up so that you play by a certain set of rules, which in most instances also set you up to fail. Don't be afraid to break away from pre-defined processes and approaches when it's the right thing to do.
You have been hired because of your expertise. Part of your responsibiliy as an expert is to apply your judgement to the obstacles and opportunities that come your way.
And, of course, learn from your mistakes.
- Created a functional statement
- Identified major processes at a high level and
- Identified interaction points with other groups.
6 July 2008
This view of organisational structure has two dimensions, which each have strengths and weaknesses.
A broad span (figure 1) means that there is direct communications and interactions between the manager and their many reports (i.e. people who report to them.)
The benefits of this are that everyone deals with the same manager, and as a result everyone is more likely to be aligned with the manager’s vision of what should be done. The disadvantages are the cost to the manager in terms of time to deal with each staff member.
A tall span (figure 2) means that there are more layers of management between the frontline and the top level management, and as a result there is the opportunity for the vision and communications from the top to be muddied by misinterpretation. The benefits of this model are that the managers all have more time to spend on each person and the work at hand.
Naturally a balance between vertical and horizontal spans has to be found for each organisation, and of course the balance changes within organisations, depending on a number of things such as the complexity of the work, the worker’s self sufficiency and the culture of the organisation.
A couple of examples to illustrate this point;
- Production line workers typically work in a large worker to manager ratio (say 25:1) as the work is low in complexity and the worker is basically self sufficient.
- Call centre workers also have a reasonably large number of workers to managers, but this varies depending on the complexity of the role. Simple mass market enquiries (e.g. paying a phone bill) might have staff to manager ratios of 25 or more to 1, whereas complex business to business transactions may be supported by smaller teams with say 10:1 staff to manager ratios.
- And a bunch of high end business consultants might work in a team of 4 per manager because their work is highly complex.
So, what does this mean for project teams?
There are multiple lessons to be drawn from this concept. And they can be categorised into
- Organising project teams,
- Identifying and managing stakeholders and
- Designing future modes of operations for clients.
And there is potentially some lessons that can be learned for managing requirements.
More to come, but first; Your thoughts on this topic?
5 July 2008
3 July 2008
1 July 2008
I wanted to write about the role of the project sponsor, but found three good blog posts that start the discussion for me. Have a read;
- Looking for your sponsor?
- Effective sponsorship 1 (presumably part of a series but I haven't looked)
- Roles and responsibilities of a sponsor
We'll come back to these points again in the near future.