30 August 2008

The project management process #4 - Change Management

This is 4th presentation in a lecture series I am delivering.  It deals briefly with change control and then gets into change management - getting pople to adapt to new ways.

29 August 2008

BAs and PMs together

Watch the clip while you read this.



BA: To do this project properly we really have to add features A, B and C. And we should also deliver D and E for the users.

PM: But our budget is only 1 million simoleons

BA: Everything adds value in the long run and should pay for itself.

PM: And we have to finish by midnight. How can we get all this work done? Find some corners and cut them.

BA: I am not going to short-change these people. I have to live with the consequences of the product we deploy. I have a reputation I have to maintain. These people trust me and I am not going to sell them out.

PM: Well, what can we do? Take longer? Blow the budget?

BA: Look, I'm not the one who sold them on an unrealistic plan.

PM: The plan wasn’t unrealistic, until you came along and started to bloat the requirements...

BA: The get another business analyst. I don't need to be here.

PM: Well, I need a BA, and (grudgingly) you are pretty good at it.

BA: Ha! So you need me then.

PM: I guess so, but what can we do?

BA: I have a plan...

PM: That's ridiculous! It's way outside the scope of this project.

etc. etc.

Heard this story? Now we can put it to music.

28 August 2008

Project Schedule Management

I don't usually delve into the technical aspects of project management skills on this website, but I am working with some peers at work on improving our skills and knowledge. It's my turn to dig something up on networking and scheduling.

Why do it the hard way?

I turned to my friend Slideshare and had a look around for some content. I found the presentation below.

It's not a neat and easy to follow, entertaining story. It's a bunch of crammed and concisely articulated facts and tips around scheduling and resoucring a project team.

Contents include network diagrams (PDMs and ADM), bottom up, function point and estimating techniques, critical chain, crashing and more.

If you are thiking about improving your knowledge, or even prepping for a PMI exam, this might be a good pack to read through.

You'll have to view it full screen to be able to read it, but go ahead.

In particular I learned about three point estimates; balancing the optimistic, pessimistic and most likely estimates and then applying a formula to get to the best estimate for your schedule.

Tell us all what you learned from it.

Project Time Management
View SlideShare presentation or Upload your own. (tags: pmp time)

26 August 2008

The wall is the desk of the future

Great visuals and a story many of us can relate to.

The Wall
View SlideShare presentation or Upload your own. (tags: diagram xplane)

24 August 2008

Networking, Brokerage and Business Analysts

Graham Durant-Law writes a fascinating blog on network analysis in the project management field. He is researching the field and produces a number of presentations on the topic of networks and complexity.

Complexity of course is something we strive to avoid or at least manage away as best we can.

I found this idea below among the presentations on his site. Have a look at this slide pack I put together – it’s an expansion of one of his slides on the various roles people can plan in managing communication on projects. (All I did was turn one slide into several – the IP is all his.)

Graham highlights these five roles and describes the way they can contribute or inhibit the flow of information, and how their influence can be as an outsider or insider.

1. Coordinator
2. Gatekeeper
3. Consultant
4. Representative
5. Liaison

The topic of project roles came up at the IIBA blog this week in the context of different types of BA roles; Kevin Brennan describes two styles that the BABOK tries to accommodate - the consultant and the facilitator.

Graham's model highlights that there are a broader range of styles that the BA can apply to her or his work.

When you've read the presentation, and if you like, visited Graham's content (at Knowledge Matters, I’d be interested to know how you play your role as a BA.

5 Project Roles
View SlideShare presentation or Upload your own.

23 August 2008

22 August 2008

Which role is more important?

Nathan sends me a link to an article at CIO looking at the hottest 16 jobs in the IT industry.

Yes we are all in there...  The jobs are categorised into classes, and the demand for BAs is apparently greater than the demand for PMs.

I ask this question;

Is the BA role considerred of high value when it comes to project delivery, or is there simply a shortage of skilled and experienced BAs out there?

Link: 16 Secure IT Jobs.

Picture by Capt Kodak, CC @ Flickr.

19 August 2008

Dispatches

Andrew sends us this link.

Apparently only 15% of business analysts come from the business side of the business-IT divide.  In my experience it's where most of the best ones come from.

What about you?  What do you think?


(By the way - our survey is almost over.  Where do you work? Business or IT?)

Article: In-house app development fraught with waste!

18 August 2008

Capers Jones on Function Point Estimates

Capers Jones has written an article introducing the concepts and methods of function point estimating.  It's useful knowledge for project managemers, analysts, designers and tech team leads.

The article is particularly useful as it gives you a simple framework to try FP estimating yourself.  It also points you at more sophisticated tools in case you want to explore further.

Mr Jones is an expert in the field and author of several books on IT estimating, quality and more. See what he has to say at Modern Analyst.

16 August 2008

The Project Management Process #2 - Portfolio Management and Project Selection

Here is the second in the lecture series.  Again feedback on the slides is welcome.  If you can do better I am happy to tkae your advice.


15 August 2008

PMI on the value of Project Management

PMI have produced a webcast discussing the value of project management to business.  If you don’t have time for a 90 minute video try the associated presentation pack. 

Key points;
  • Implementing Project Management competencies clearly demonstrates increase value realisation for organisations that take it up
  • One project management method does not fit all organisations, or even all projects within one organisation.
If you have the time - have a listen.  Interesting stuff.

(Picture by ToOliver2, CC @ Flickr.)

Truth in advertising?

14 August 2008

IEEE Std 830-1998 -Software Requirements Specifications

Team





I thought I should call your attention to International standard IEEE 830-1998.  It's a standard for software requirements specifications.

IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications

IEEE have created standards on a range of engineering disciplines from networking to nuclear power.

A summary of it's contents is here where you can also buy a copy.  Anyone read it?  How close is it to the IIBA's BABOK approach?

Is requirements management an engineering discipline?  Some think so, other disagree.

Opinions?

(picture by Exolucere, CC @ Flickr)

12 August 2008

Why reverse engineer requirements?

A discussion at the Agile Modelling Group put this picture into my head.

The original question was about how to go an document requirements for an existing system. My initial response was why would you want to reverse engineer a system back to requirements?

It makes sense to me to get a full picture of what a system can do - and so document features, but I can't get why you would take things back to requirements.

After all, requirements are a statement around a particular problem or opportunity, not a design specification.

The diagram below came to me care of a comment made by Jon Kern.


Jon notes that not all formally accepted requirements make it in to the final release. Sometimes they are too hard, sometimes you run out of time and money before you get there.

Additionally extra non-formal requirements often make their way into the final release. Non-formal requirements arise from a number of places including uncontrolled requirements changes, requirements elaboration and developers realizing that a neat feature is just 30 minutes of code away.

So at the end of the day, a system doesn't match any particular set of requirements anyway.

Now, there is a case for re-using requirements. After all, if you have a set of standard requirements for say, logging into a system, why not re-use them. It saves time and builds consistency.  But requirements re-use isn't the same thing as reverse engineering a system to establish requirements.

I ask again; what value can there be in this? Any suggestions out there?

10 August 2008

What is Project Scope? What should it be?


I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to definitions of scope. I want to comment on it here because I think it’s an area that a lot of us have trouble with – both understanding and managing it.

Project Scope
Traditionally project managers focus on scope as the body of work that will be done to deliver a working product (or solution) to the customer. We use phrases like ‘the scope of work’ to define what we have agreed to do. And we use the scope of work to define our expected efforts and thus our pricing or budget forecasting for projects we are about to undertake.

The Scope of Work is part of the project management ‘iron triangle’ which is a paradigm that suggests that there are always trade offs between the work you need to do, the money you need to spend and the time needed to complete a project.

Product scope
Julian points out that the IIBA/BABOK’s approach to scope is framed around the delivery of a product/solution. This approach comes out of the realm of product management and is about defining what a product can do in terms of features and functionality. Many modern software project managers also talk about scope in the context of the product rather than the work to be done. In this context we talk about the “scope of the product” or the “scope of the solution,” not the scope of work.

Project issues of cutting back scope are usually referring to cutting back features to be delivered – which is of course related to the effort to be expended (ie scope of work.)


What's the problem?
So, Traditionally project managers are talking about the scope of work and business analysts (and product managers) talk about the scope of a product.

The opportunity for confusion between project team members over what particular scope is being talked about presents a problem. Now you know about it the problem has diminished.

The question I want you to ask yourself is, as a project manager or business analyst, which definition of scope is more important?

The problem I see with the “Scope of Work” approach comes in three dot points;
  1. We still aren’t mature enough as an industry to be certain that a particular amount of effort will result in a reasonable product (or solution to the client’s problem.)
  2. While understanding underlying costs is important, it is not as important as quality. Or better yet; it’s not as important as value. Remember the phrase “you’ll remember bad quality long after you forget the price?)
  3. And lastly, at the end of the day, if you do exactly what you said you were going to, and the client has paid you your pound of flesh, will either you or your client be satisfied if the solution has not been delivered? I didn’t think so.
I figure this is fundamentally related to whether you should take an outcome focused or process focussed approach to your work.  There are arguments for both of these, and maybe they can live together, but I feel that you have to pick one or the other as the main choice.  And my choice these days is the outcome focus.

People, what do you think?  When you talk about scope today which one are you talking about?  Is it working for you?

I also recommend you go read Julian Sammy's post on this topic here.

(Picture by pbo31, CC at Fickr.)

9 August 2008

The Project Management Process #1: An introduction

In my spare time I am teaching a project management course to some young masters degree students.  For me it's fun to share my knowledge and see them develop over the semester.

Unfortunately the course comes with some prepared slide packs which hit all the "don'ts" on the presentation tips slide packs out there.

We liven it up by presenting most of the lecture content on the whitebaord and verbally rather than follow the screen - but I have had a crack at re-doing some of the slide packs. 

(It's always subject to short deadlines and lack of sufficient time.)

Anyway - here is the first.  Comments and constructive criticism are very welcome.

Dear Bas - Conversations with the Project Shrink

Bas de Baar, the Project Shrink, and I are convesing on project management, and in particular professional development.  The conversations is across both our blogs.  You can go back to the beginning, or just start reading here.  Your opinion is important to us, so please - drop us a comment.



Me? Professional memberships? I have none. Today. Kind of.

I joined the IIBA when I first heard about it, and even helped organise some IIBA events in Melbourne while I was there. I also went to a few PMI events during the same period.



Now however I am not in a major city and so there are no local associations. That said, I always involve myself with my colleagues at different workplaces and like to get discussions about how best to tackle problems and build competencies.



I also have the option of joining and associating with online organisations. And I have taken the opportunity to become an active member of some of these communities; primarily MyCatelyze, RNQG and Modern Analyst.



In particular I have been pretty active at Modern Analyst. It’s mainly a once way thing – as an experienced person I share my opinion with the many juniors in the forums. It’s still rewarding.



And of course there is the discussions we have at Better Projects, Project Shrink and our other project blogs.

Lastly I have taken up another opportunity. One day a week I trave to Sydney and teach project management to university students. I enjoy it, and so do they.



So yes. I have work based communities that I participate in. And I fully recognise that my participation in these various forums has helped me develop as a practitioner.



What’s the lesson here?

I think it is this; no matter where you are in your career, and no matter where you are in the world, actively getting involved in discussions about how to do you job better will help you. Whether it’s asking questions, discussing ideas of sharing your own views on how things should be done – if you are doing this, you are improving your professional capabilities and continue to stay well ahead the pack when it comes to delivering value to your clients and satisfaction to yourself and your immediate team mates.





Now, another point.

Today I m not a member of the PMI or IIBA and so am not on the inside. As an outsider it is easier to criticise things you think are not good. I don’t make claims to be a journalist, but that is one of the ideas around journalistic independence. They should be independent in their investigating in order to bring the truth to the public.



It’s a little less dramatic in the context of a blog on projects, but I do like to think my outsider view of the industry organisations’ provides me with the opportunity and lends me some credibility when I say



I think the BABOK has a serious flaw in the way for example it treats requirements communication, or when I say the PMBOK’s view on Scope is one of the reasons for so many over budget projects.



Bas, Are you an outsider looking in? Are you an insider selling something?



Readers, What do you think about this?



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.









Picture care of rhoadeecha , CC and Flickr

8 August 2008

4 August 2008

Agile PMO

Some time ago, I wrote a post about building a new department during a restructure. We've been working on how to institute processes that are not too much overhead since we have a very small staff with many customers to support. However, we are required to meet some very strict reporting and accounting guidelines for legal reasons. That's why I've been agitating for an Agile PMO.



In this article by Tamara Sulaiman, she talks about how the PMO fits into an Agile environment. Ms. Sulaiman makes some excellent points but two of them really jump out at me.



The first is "Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy.". This is a problem I've been struggling with in our current situation. The article references This article at the Agile Journal by Brent Barton. This is an excellent idea for what we are trying to do. In the article, Mr. Barton talks about how the Product Owner should run the Meta-Scrum since they have the roadmap. This is exactly where we are trying to go. He also mentions that the group has to be ready for full transparency. I don't know if everyone is ready, but I think this is a step in the right direction to get teams out of the stove-pipe style of work they've been used to and into something that works better for everyone.



How do we, as a small group supporting a large number of projects, make sure we all have the information we need to keep up with the current portfolio? How about a Scrum? How about using a Scrum board to track where projects are and which team has the current responsibility for them? How about a nice, obvious place to store the project backlog so everyone knows what projects are coming up that need to be planned for?



I'm working on creating a board that will help answer these questions. I'll let you know how it works out after we've used it for awhile.



The second point that I want to mention is "Gather and communicate portfolio level metrics to the organization.". If the only type of project I was concerned about was software development, then I would be all over AgileEVM. However, we are trying to manage projects in all areas of IT - systems, networking, applications, security, telecommunications, etc. This makes it somewhat harder to find consistent measures. We may just use separate measures for progress but try to find some common measure for business value.



Any way you look at it, we are playing Jenga in our implementation of Agile. We'll see how solid our players are.

3 August 2008

Developers as stakeholders

Assumptions... 


This came up in a conversation today;  Are programmers/developers stakeholders to the project?  And of so, do they have a voice inthe requirements?



My view?



Yes developers are stakeholders.  Their personal reputations and future job opportunities are related to the quality of the project.  So yes, they should have a voice in requirements definition.



Even if they weren't stakeholders their opinion matters.



Some requirements managers take a view that the full requirements set should be deliverred to the solutions team (ie the developers, or a solution design team) and it's up to them to work out what can and can't be done within the constraints of the project.



That leads to two problems that I can think of off the top of my head;

  1. Developers can do anything given the time (they truly are magicians) - so the answer to "Can we do it?" is always yes and the cost aren't properly addressed, and

  2. Requirements prioritisation is not mapped to do-ability.  So hard, high risk requirements are addressed first because the client wants them, even though they may derail the whole development process.

But developers are stakeholders, so Analysts MUST discuss the business requirements with them up front and fctor in their views into the product vision.

1 August 2008

Social Project Management

Afew months ago I came across this presentation via Bas' blog. It's food for thought.

Take two minites and read it, then pop over to Leisa's blog Disambiguity.