If ... (Good Advice)

Good advice even 100 years later; for any project or program management professional; male or female.

http://www.goodreads.com/work/quotes/34072-if-a-father-s-advice-to-his-son

1 Minute Intro to Programs & Projects – Their Definitions and Descriptions

"History is lived forward but is written in retrospect. We know the end before we consider the 

 beginning, and we can never recapture what it is to know the beginning only."

~C.V. Wedgwood

The quote above got me thinking that as unlikely as it may seem to those of us already in the profession there are still a lot of people who are just beginning to learn about it for any of a number of reasons. Thus, following the theme of this site, the following information is a one minute introduction into programs and projects. The source is from the PMI (Project Management Institute) standards and that is an excellent source for many publications of these topics.

A project:

• is a temporary endeavor undertaken to create a unique product, service, or result (temporary does not necessarily mean short in duration)
• has a definite beginning and end
• ends when the projects objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists
  

A program:

• is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually
• may include elements of related work outside of the scope of the discrete projects in the program
• also includes components for managing effort and the needed program infrastructure
  

A portfolio:

• refers to a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives
  

Thus, as shown in the drawing above:

• Portfolios encapsulate Programs
• Programs encapsulate related Projects
• Projects encapsulate deliverables
• Deliverables are comprised of tasks that need to be efficiently and effectively accomplished in order to realize all of the successively larger views and management towards realizing the required business objectives
  

Projects and programs are carried out using project management and project leadership techniques.
Project management:

• is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements
• is accomplished through the appropriate application and integration of the 42 logically grouped project management processes comprising the 5 Process Groups
  

Project leadership:

• focuses the efforts of a group of people toward a common goal and enable them to work as a team
• establishes and maintains the vision, strategy, and communications
• motivated and inspires project participants to achieve high performance
• fosters trust and team building
• influences, mentors, and monitors
• evaluates the performance of the team and the project
  

Thanks to all my family and friends who have offered suggestions to improve the launch of my blog! Updates are in progress and please keep those ideas coming!

But let us all also take some advice from www.dilbert.com and December  3, 1999:









:-)

~Leyton

What Went Wrong? - Humour

Okay -- enough of the long posts -- at least for one day. ;-)

Here's a bit of project management humour about the importance of planning and communication in any project. It's an oldie but a goodie. :-)

This is the story of four people: 

Eyerybody, Somebody, Anybody and Nobody. 

There was an important job to be done 

and Everybody was sure that Somebody would do it. 

Anybody could have done it but Nobody did it. 

Somebody got angry because it was Everybody's job. 

Everybody thought that Somebody would do it. 

But Nobody asked Anybody. 

It ended up that the job wasn't done 

and Everybody blamed Somebody, 

when actually Nobody asked Anybody.

~Joan Esch

Good User Stories … continued

I was thinking about this and thinking “Well that's not very nice to leave people hanging like that about the 'S' in INVEST and what defines “small”. Especially when I realized I forgot about a psuedo-acronym.

Good User Stories enable the team members and project's stakeholders to INVEST in what is being set as an objective.  Put another way, they communicate functionality that is of value to the end user that promotes further communication when the story is being worked on. And like I said in my last post, 'small' is subjective and because of that the definitive answer is 'well that depends.' Seriously though, in preparation for this post I Googled 'agile INVEST acronym' and it returned 'About 203,000 results'. I Googled 'user stories' and it returned 'About 1,310,000,000 results'. That's how subjective this is. No worries though, it really is a lot simpler than all that. 

If you really wanted to you could probably scan through some of those results and quickly find definitions like 

• anything longer than 2 or 3 or 4 weeks is when it becomes a them or an epic
• small enough to fit within a sprint or iteration and deliver value from it
• the right size is usually about a work week
• shorter than a week is too small 
• a day or two
• and so on and so forth

And you know what …. yup, you got it, they're all correct …. for them! The reality is that when user stories are being written and sized (size 'small'; please :-) ) there are still four more factors. Those factors are time, work effort, risk and overall complexity; I'll save “complex versus complicated” for another post. :-) 

Time is the easy one and because it's easy that's where a lot of people new to Agile stop … and then they have schedule overruns just like they did in the traditional (waterfall) way of doing things. 

Work effort is the first factor (of these four) that starts to ask people to think about who and which roles need to be involved to deliver something of value. After all, if your stories are specific to one person or role you've probably just created broad, high level tasks and labeled them user stories. 

Risk – well this could be a book all on it's own; well what do you know … it is! ;-)   For now, let's just say big risks should equal smaller sizes unless there is a high tolerance for delayed feedback.

Overall complexity as I eluded to above is at least another post and are books all to themselves when you start thinking about complex adaptive systems and other systems theories. For now, let's just say the harder it is to describe the story on a 3x5 card so your intended audience understands what is being asked for the more complex it is.

Oh, that missing pseudo acronym? It's the 3C's – Card, Conversation, Confirmation. Just click on the link for the details in the Agile Alliance Guide.  :-)