This video, produced by Hamid Shojaee, offers a quick, yet very informative view of scrum. Scrum is an incremental approach to project management in which the major roles include the scrum master (essentially the project manager), the product owner (or stakeholders), and the team (designers, developers, testers).
The image below gives a visual to the scrum process.
For more on project management, please visit http://www.managepro.com.
Check out the video above to learn the fundamentals of project management. Besides time, cost and scope, quality and risk factors also need to be managed. But when it boils down to it, Project management is nothing more than being accountable to work smart. And working smart is really a “head’s up” manner of working that is sensitive to people and the Outcome, while making the adjustments to reach both within your time and resources.
To learn more about project management, see http://www.performancesolutionstech.com/category/project-management/
An important, but not apparent, set of factors affect
successful use of project management software. These factors can trip
you up if you’re not aware of them.
Time is short so let’s take a look at the hidden Design factor in this
and the subsequent blog, and how it impacts you.
Before we get started on design, a brief baseline. Project
management software represents both a promise and a
challenge. The promise looks something like, “if you use this
tool, you’ll be on track, on time, within budget,
complete what you set out to do, etc…”
However, it turns out that the (reality) challenge of completing the
project is bigger than the promise, given all the failed or over-run
projects that occur – that presumably were to be avoided by
using project management software.
I’m sure you’re aware of that – and if not, it’s easy to research
via Google.
So here’s the first thing you should understand about project
managementsoftware design – this directly effects your time and
dollars.
1. Project management software comes in all
sorts of design configurations, from simple to complex.
Theoretically you should choose no more complexity than
is required to complete your job, as increasing the software’s
complexity always requires more time, effort and cost to use.
If project management software was equivalent to tools for
digging in the dirt, you would probably agree that they range
in complexity from shovels to large earth moving equipment.
So, common sense would suggest that you pick the tool
that’s right for the job… and only spend as much money
as you need to. Right?
But, here’s what most people don’t think about. What does
your project mix look like on the job? What’s the % of time
spent working simple vs complex projects? E.g. if only 5%
of your time or resources is spent on complex projects,
you wouldn’t buy a complex software with all sorts of bells
and whistles… just because it was the biggest or
market leader… or would you?
Take one more look at this. What if you looked at the
needs of the people using the project management software.
What % of your people working on projects need something simple,
versus complex or high powered? I’m betting the % on both is
a 10/90 split or higher – with 10% or less going to high powered
requirements.
Well, it turns out actually lots of people/organizations buy more than
they need, or worse… can sustain. This is an easy one to
trip over, but why?
Because it has an immediate sense of comfort. We are immediately
soothed by the purchase and feel that we have all the features we
could need or want to compete projects on time and accurately.
It’s a protection against the distressing discovery that they have
purchased something that will “let them down” or that other
people can criticize as under performing. It avoids the dreaded,
“Why did you buy that software?” challenge. Reminds me of
that old phrase, “no one ever gets fired for buying IBM.”
Design factor, as it effects the simplicity vs complex dimension,
can trip you up in two ways.
1. Over Buy: You can protect yourself against not being sure about how
much you need and just over-buy, get something bigger than
you need… just in case (and then struggle with a low % of people mastering
it’s complexity).
2. Under Buy: You can also buy something “simple.” But again, if you don’t
accurately assess your needs, it’s easy to trip and inaccurately�
determine if its simple design has enough flexibility and capacity
built into it to avoid limiting you and your team going forward.
Here’s the bottom line:
Most of us need a flexible project management software.
In fact we need it much more than we realize – not only to
match up well against the range of projects we are managing,
but also given the range of people’s need working on the project.
One tool that can be work simply when that’s all that is
required, and yet have the power built in when we need it.
But, an important hidden gotcha, is that along with flexilibility,
project management tools also need to leverage
information really well. The valuable informaiton required to make decisions.
That’s an issue, especially when you begin looking at simple tools, and
really that’s pretty much all of them.
We’ll dive into that on the next blog. See you there.
I read an interesting blog by Jim Scheel’s titled “We’ve been Managing
Software Development all Wrong” and it got me thinking about
project management models and the discussion about PMBOK
or PRINCE2 or Agile… and I immediately think that the
whole concept of which model is right or wrong is misplaced.
I think the whole project management discussion and process
would do much better if it took lessons from music.
 |
 |
 |
||
 |
||||
 |
 |
 |
 |
|
YouTube: Hide Player | Play in Popup | Download
That probably sounds strange, but let me explain. In my life, I’ve had the
opportunity to play classical music, play rock and roll music
at clubs and parties and with Elvis impersonators, and jazz with
people like Benny Goodman.
They all are different styles of music, they represent certain differences
and certain parallels in getting from the start to the end of a piece.
They all have a place, serve a function, have a following. You wouldn’t
typically say one is right and one is wrong- just different.
If you compared music to project management, you might say both
are a way of organizing people and their actions to generate certain
outputs. Yikes that sounds detached.
What I’m getting at is this:
Playing music is roughly equivalent to project managment.
When playing classical music, you play what’s written, so that dozen’s of
people can all produce and finish largely an exact copy of what was
originally penned. Very structured. Very defined. It is akin to one form
of project management as perhaps best applied to producing known
outcomes.
In playing the blues, you usually are working over a 12 bar chord
progression, with a particular use of thirds and a base pattern that
gives it that unmistakeable “blues” sound and feel. It is much less exact
or prescribed than classical, yet it has a defined sequence and feel
that has to be created for it to sound “right” to the listeners. Again,
it represents a different form of project management. One that allows
more latitude, but still moves through various phases or gates.
When it comes to playing jazz, or any genre for that matter, there’s lots
of room for freedom of expression, interpretation, adaptation, how long
you play the song (e.g. how many repeats), what exact chords you play from
verse to verse, and for adapting to the unexpected…
Jazz is still music, the players still work within a structure, they still start
and stop and they still produce an intended outcome. But if described in project
management terms, it’s a very different model, perhaps more like Agile
than PMBOK (classical).
Bottom Line:
Project management and playing music have some strong parallels, and
my perspective is that project management would benefit from embracing
the fact that there are different styles or forms of project management, just as
there are different styles or forms of music.
Part of the differentiator seems to be how much the project is to be a
replication of defined, known requirements, versus an improvised creation
with a roughly defined outcome (e.g. let’s play Stella by Starlight in 3/4
instead of 4/4, key of G, you take the first chorus and we’ll finish by playing
it one moretime through from the top).
Perhaps the less we know of the exact outcome and all the obstacles we will
have to overcome to reach that outcome, the more project management
needs to move from a classical to blues, to jazz orientation.
Links:
Over the years, I’ve worked with so many different organizations, executives and line staff that I increasingly wonder if project management represents an accurate, and therefore helpful model for how people work. Does project management maturity model represent reality for most of us?
I don’t think so, at least in terms of how the majority of our time is structured. In fact, I believe a todo or task management maturity model might be a better fit for most organizations. There is a lot of excellent material written about project management maturity models, addressing the degree to which or how complete, how systematic and how comprehensively organizations utilize a project management system to organize and complete their work.
However, if you take a deeper look at most organizations, aside from formal schedule based production work, like you might see in construction or a production environment, the project management maturity model doesn’t seem to match up to how work gets organized 95% of the time. Often it sounds like another universe.
Why? First of all I don’t think most people’s work gets organized into projects. I think for most people it gets organized into a series of habits and tasks… You know, stuff you need to do as part of the job, which if it you’ve been working it very long, you know from experience (e.g. it’s a list in your head). Secondly it’s stuff that comes in via various “channels”, e.g. email, meeting requests, phone calls, and deadlines of one sort or another, which may be written down somewhere or in multiple places, or it may be represented by folders stacked on your desktop, a collection of phone messages… maybe post-it notes stuck to your monitor. Note that referencing a project plan is probably not one of the predominant input channels for most people.
Let’s face it, most of us spend relatively little time working a project plan, mostly our day would be better represented by a series of written and unwritten todos.
After facing the reality that most of work is organized around todos, not project plans and the supporting work breakdown or task structure, something else strikes me. For the most part, we are not plan driven, we are “prompt” driven. By that I mean we rely upon prompts (not a project plan) to get to the next todo. The basic prompts we all use are:
My observations are that most people we work with not only infrequently reference a project plan, but they also would generate more immediate benefits from improving on todo management than project management. Better management of todos across an organization is the prime area to improve on for a majority of organizations, if not a precursor to improved project management.
Maybe instead of project management maturity model, we need to focus on a maturity model for todo management, e.g. to generate a “maturity of systematic approach” to the structure for managing todos to result in improving the success rate at delivering on objectives, budgets and timelines. Here’s a couple of initial suggestions about what a mature Todo Management system might look like:
1. Todos’ are visible and leveraged by tracking in one system. In this system, todos represent a fundamental work tracking system that needs to be formalized, not scattered across various systems.
2. The formal system provides a prompting for delivery of todo based requests and commitments (within a calendar, within a list, auditory and email prompts).
3. Most people gain from attaching todos to topical based outlines, as that seems to help secure memory associations and help avoid details slipping through the cracks.
4. Most people need a follow-up system when assigning todos to others, e.g. a vehicle for getting feedback on the request they made, without having to initiate the follow-up themselves.
5. Incoming email, including attachments, needs to be easily parsed and reformulated into todos that are frequently embedded in the content.
Un-abashed Plug. If you are interested in improving todo and task management at your work place, we don’t think there is a better system for managing todos, attaching them to a concept based outline of departments and project listings, and assigning and tracking them across people than ManagePro. In the upcoming next release we even provide a performance measurement based on each individuals’ ability to complete todos each day.
Bottom Line: The maturity of an organization’s system and process for managing todos may better predict an organized work flow and positive outcomes than a project management maturity model. Does it for the organization you work in?
Implementing a new project management tool can be a great investment or a failed and frustrating experience. To help ensure you get the results you’re looking for you need to evaluate your business needs.
Success Starts with Responding to the Why Questions. Before you begin defining What the ManagePro tool is, or How it is to be used, or even Who is going to use it, start by building a compelling case for utilization with your work group. Build it by addressing the Why questions. Below are just a few you might consider having your workgroup discuss:
1. Why use new project management tools now?
2. Why can making even a simple tool, like ManagePro, work be difficult?
3. Why do tools work in one organization and not another?
4. Why are people reluctant to use tools?
Here are some points to consider in assisting your discussion:
Why talk about deploying
Project Management Software?
n 1999 PMI survey study MS Project ranked as most popular PM tool, lowest in overall satisfaction and lower than MS Word as most frequently used PM tool
n “Less than 30% of all change efforts actually succeed in meeting the expectations of key stakeholders.”
Conquering Organizational Change by Pierrie Mourier & Martin Smith
“… the most frequent, but often overlooked cause of implementation problems is ignoring people issues.”
from a 5 year study by Cavanaugh Leahy & Co. 1999
Successfully Deploying PM Software
n Missionaries, the gospel of productivity and Cannibals
n Isaac Newton, Thomas Kuhn and the Deployment Wall
n Deployment as PM and the Technology Usage ladder
n Change Management and the Push-Pull leadership model
Missionaries, Cannibals
and the gospel of productivity
n Early adopters as missionaries for improved productivity
n Missionaries eaten by cannibals within first six months
n Most people adopt software if easy and mandated, not to be more productive
n The BIG SECRET ABOUT DEPLOYING SOFTWARE–
“it’s not productivity, it’s a combination of change management and leadership”
Isaac Newton’s (1642-1727) perspective on software deployment
n 1st Law:
An object maintains its state of uniform motion unless it is acted upon by an external unbalanced force.
n Translation: The Power of Habit
People maintain and are at rest in their patterns unless activated by an external “unbalanced” (i.e. judged to be not-fair) force