Top Tags

Tag project management

Entries 9 Total

Frameworks.

Jul 10, ’11 12:30 PM

I think I’ve always been interested in solving problems, and when I’m asked to describe my strengths, “problem solver” is a phrase that immediately comes to mind.

In my experience, there are three steps to problem solving:

  1. Identify & understand the problem
  2. Choose or build a framework in which to solve the problem
  3. Come up with the solution (or solutions)

For many of the problems I’ve tackled over the past several years (many in the form of specific projects), the “framework” has remained fairly constant: it typically involves the creation of a team organizational chart and a conceptual visual that depicts the project’s “end state.”

While this model works well for project management, it doesn’t fare as well for creating business models.

Historically, business models tend to be verbose and full of financial analysis and risk-oriented topics.  In many cases, this results in a business model that is too detailed, lacks true understanding and prone to gaps / errors.

In the book “Business Model Generation“, the authors present a different way of creating business models through the use of a modular graphic, or “canvas.”

This “canvas” approach streamlines the process of creating new business models by allowing participants to focus on the core subject matter vs. having to constantly remember how the pieces “fit” and whether anything has been missed.

Here is what this framework looks like:

I found this approach to be particularly useful, so much so in fact that I used it during a recent interview.  One of the questions posed involved identifying several key aspects of introducing a credit card portfolio to a company’s product suite.

To answer this question, I drew two canvas’ on the whiteboard.  The first represented the “as is” state and the second represented the future state, one where I had successfully integrated a credit card portfolio into their business model.

I used these two visuals to explain or identify:

  • what would need to change
  • where resources would be required
  • sources of revenue
  • potential opportunities
  • sources of risk

Once I was able to tell this initial story, I found I was able to answer additional questions much more easily now that I had a solid foundation to work from.

When problem solving, the use of a problem solving framework is, I think, essential to long-term success.  Once you find the right framework, you can continue to refine and expand its use, which can lead to more efficient use of your time and can open up possibilities in other areas as well.

When asked a problem that involves getting from point A to point B (physical location or point in time), duplicate the framework to show what sections need to change.  Once you have a grasp on the original framework, replicating and showing the delta between the two versions is easy.

It’s at this point where you can spend most of your energy solving the real problem, and that’s where the fun really begins!

Comments Off on Frameworks.

The (New) Hierarchy of Needs – Part V

Nov 15, ’10 8:22 PM

[This is the final segment of a five-part series on project management that is based upon Abraham Maslow’s “Hierarchy of Needs”]

Problem Solving

The next level starts to go into the core of the project – problem solving.  This is essentially what all projects are about.

What is a problem?  A problem is an obstacle which makes it difficult to achieved a desired goal or objective.  Problem solving can be fun as it helps to build a certain skill set regardless of the topic.  In the project management space, problem solving is the name of the game.  While many problems may be obvious, there are many that will not be as obvious and may remain hidden.  It’s the job of the project manager to uncover these hidden problems and take steps to address them.

To ensure understanding, hidden problems are those that are known by the project team but aren’t being surfaced to project leadership.  Team members are more likely to hide problems if they don’t have confidence these problems will be addressed.  Problems can also remain hidden if there isn’t a clear understanding of who can solve them.

Your role as project manager is first and foremost your relationship with the team – if team members have a clear understanding of the objective and team organization, and have confidence in your ability to lead, problems will be raised much more rapidly and the team will be able to make greater traction in the long-run.

Thus, your ability to lead, instill “order” and “structure” and tackle the tough problems are all very important in this “layer”.

Momentum

At the top of the pyramid is momentum – that’s what ultimately keeps the project going!  Initial momentum naturally follows the layers just described, but it ultimately requires a core belief that the project will be successful.

As shared earlier, the ultimate goal of this new hierarchy is to have every team member reach their full potential.  While this is a lofty goal, if you want to deliver a quality product / service in a short period of time, this is what you need to shoot for.

As with any moving object, ensuring that you maintain positive momentum is ultimately dependent upon the source of “power.”  In a project, that source of power is the team and the hierarchy tiers that fall just below this one.  The more organized and refined the underlying layers, the less “friction” and the longer you can maintain positive momentum over the long-term.

References:

Comments Off on The (New) Hierarchy of Needs – Part V

The (New) Hierarchy of Needs – Part IV

Nov 1, ’10 8:58 AM

[This is part four of a series on project management that is based upon Abraham Maslow’s “Hierarchy of Needs”]

Accountability

The next level up moves beyond this “foundation” and starts to get into the tactical level – “who’s involved and who’s accountable?”  In this layer, we build an organizational chart that shows who is involved and where each resource “fits”.  Discussions around “workstreams” and communication pathways can be found here.

In order for a project to be successful, accountability needs to be defined and enforced at multiple levels – not just with the project performers.  All project participants – including stakeholders – have a specific role to play, and if they have a role to play that means that they are accountable for “something”.  Said in another way, if it’s difficult to define what that resource is accountable for, then they should not be part of the project.  It’s really that simple.

Creating a team organizational chart is the first step in this accountability definition.  The key is that there should be ONE and only ONE leader.  Ensuring that the leadership chain is clear and unambiguous in the visual is extremely important – if it’s not obvious who is running the project, then you have a problem.

Having a technical lead, for example, can be beneficial but only if the structure is defined such that the technical lead reports to the PM.  If the PM and technical lead both report to the sponsor or customer, then you have an accountability problem.  Similarly, if you have multiple customers, how does that working relationship look?

Again, if it’s not obvious in the visual, it’s not going to be obvious in practice.

Another tip is to keep the core team as small as possible.  Why?  Mainly because the more resources you have, the more communication paths you create.  Communication paths are critical to a successful project and need to be carefully managed.

For example, in a “loose” organizational structure, you are more likely to have communication “cross talk” and duplicative efforts which impede progress.  Maintain the team organization and manage communication pathways like a traffic cop – keep things organized and life will be easier.

What happens when your project scope requires a significant number of resources?  Your core team can and should remain small.  Just divide the organization into discrete areas of accountability.  Again, keep the core team small and hold people accountable.  Careful workstream definition is key here.

I’ve learned even when people are identified on an organizational chart, it doesn’t mean they “buy-in” to the structure you’ve created.  Unfortunately, the reality is that they are unlikely to challenge what you’ve “built” because doing so can put them in an awkward position and you’re likely to receive false acknowledgement.

The key is to ensure team participants are comfortable in the role that you’ve identified, and if they are identified as a workstream lead, doubly ensure they know what you are asking them to do.

If you have the luxury of leading a team where roles are undefined, it can be beneficial to utilize Strengths Finder to truly understand the strengths of each resource.  It’s easy to assume that each person has strengths that align with the task they have been assigned, but that can be misleading.

Get the most from your resources by understanding where they excel and how they wish to contribute.

Remember, your primary goal is to build a solid relationship with the team.  If you don’t have that, it’s going to be difficult to be successful in your role.  Your secondary goal is to delegate, assume positive intent, empower the team and let things sort themselves out – you are not there to micromanage.  If you are micromanaging, you either haven’t got the right framework in place or you have the wrong resource doing that particular task (or both).

Comments Off on The (New) Hierarchy of Needs – Part IV

The (New) Hierarchy of Needs – Part III

Oct 25, ’10 7:40 AM

[This is part three of a series on project management that is based upon Abraham Maslow’s “Hierarchy of Needs”]

Constraints

The next level “encapsulates” mission and objectives within the triple constraint: time – scope – budget.

When the topic of project management comes up, one of the fundamental concepts is the triple constraint.  Needless to say, truly understanding the triple constraint and having a subsequent dialogue about each constraint is key to the success of the effort.  Interestingly enough, many assumptions are made during this dialogue that can introduce problems down the road.

For example, instead of asking which constraint is “variable”, it’s sometimes best to ask the question – if we don’t do X, what is the impact?

  • Time – if we can’t finish this by X, what happens?
  • Scope – If we cannot deliver X1, what happens?  What if we deliver X1-Y instead?
  • Budget – If we go over budget, what happens?

It’s recommended that the PM challenge the constraints as much as possible.

The customer may say that the effort must be delivered by date X, but if we fast forward to date X and the project isn’t delivered, what is the course of action?  If there isn’t a defined course of action, then that really isn’t a hard and fast constraint.  If there is flexibility, then it’s best to make it apparent.  Use the constraints to your and the team’s benefit.

Another aspect of this discussion is to think about the triple constraint when things aren’t going well.  If it takes an additional 10 resources to finish the project by time X, will the business still benefit in the long-run?  Scenarios like this should be discussed and planned for in advance so that you have some boundaries that you can work within.

Storytelling

The next level focuses on “storytelling” – describing the project lifecycle and the end-goal in such a way that is easily comprehensible by all involved.

Requirements are typically seen as the central “core” around which all work is driven from.  Regardless of the analysis methodology employed, leveraging “static” requirements as the basis for all work is not ideal.  The reason for this is that people do not think linearly – and traditional requirements gathering is just that.  Since this is materially different from how people think, gaps are likely to arise which can cause downstream problems.  Instead, a recommendation is to employ different “storytelling” methods to describe what the end functionality should look like.

These “stories” can take multiple forms:

  • writing out in paragraph form what the end functionality looks like.
  • creating individual “stories” that align with each objective.
  • describing the objectives using a mind-map.
  • describing how the project progresses over a period of time.

Creating a story isn’t necessarily mutually exclusive from creating requirements – but the story can ultimately build a better framework from where the requirements can exist.  Remember, you aren’t here to create “shelf-ware” – you’re here to create documentation that is going to drive action.

Ultimately, true comprehension comes from natural prose, not bullet points – tell the story first.

Comments Off on The (New) Hierarchy of Needs – Part III

The (New) Hierarchy of Needs – Part II

Oct 19, ’10 8:10 AM

[This is part two of a series on project management that is based upon Abraham Maslow’s “Hierarchy of Needs”]

Having managed projects of various sizes and complexity over the past several years, I was puzzled with the absence of “interpersonal” elements in project management literature given that the team is ultimately at the core of any successful project.  To this end, I formulated a hierarchy of needs that incorporates pure project management concepts along with core interpersonal elements.

This hierarchy looks like the following:

  • Momentum
  • Problem-Solving
  • Accountability
  • Storytelling
  • Constraints
  • Foundation

The key behind this structure is that it has a very close relationship to Maslow’s original hierarchy of needs.

This is important to understand because the “real” goal of any project is to have a team where each individual is striving to be the best.  If each team member can work within an environment or “operating structure” (the layers listed above) such that they are able to realize their full potential (i.e. she/he is involved and engaged) and reach a state of “flow” (self-actualization), the collective team will ultimately build enough positive momentum to virtually guarantee project success.

Thus, you can see why this hierarchy of needs and the concept (and primary goal) of “self-actualization” is extremely important: if team members are happy, the chances for project success are that much greater.

Let’s explore this hierarchy in more depth.

Foundation

At the bottom of the hierarchy is a fundamental understanding of what the project hopes to accomplish.

To this end, going through a formal exercise of defining an explicit mission statement and underlying objectives can be extremely beneficial in the long-term.  This may seem unnecessary or even foreign.  But first, what exactly is a mission statement?

“A mission statement is a brief written statement of the purpose of a company or organization. Ideally, a mission statement guides the actions of the organization, spells out its overall goal, provides a sense of direction, and guides decision-making for all levels of management.” – Wikipedia

In the project management arena, the mission statement is ultimately there to guide the project team and to serve as a “beacon” when things start to become cloudy – “Why are we doing this again?” or “Why is this important to the company / LOB?”  In some circumstances, the explicit definition of a mission statement can start to raise questions across the board where assumptions will start to be challenged.  “Oh, I didn’t know that we are really doing this for LOB A …. if that’s the case, then we need to do X, Y and Z …”

Once there is agreement on the project mission, it’s only then where you can start to identify core objectives.

There really shouldn’t be many – three or four.  If you find that you’re heading beyond that, you may start considering ways to break up the project.  Be careful that the customer is not automatically jumping to the requirements definition “phase”.  This is not a requirements gathering exercise – it’s asking “What are you fundamentally trying to accomplish?”  If you’re struggling at this stage, it’s recommended that you remain at this “level” until you and your customer are certain what you’re collectively going to do.

In some situations where there are multiple organizations involved, it is also valuable to define what each organization/department hopes to gain from their participation.  While this may not directly change things, this level of understanding is helpful when challenges arise – “I see why team A is pushing back on X, because they are really focused on Y …”.  It’s better to know what’s driving behavior now than struggle with it later on.

Comments Off on The (New) Hierarchy of Needs – Part II

The (New) Hierarchy of Needs – Part I

Oct 15, ’10 8:36 PM

“The real goal of any project is to have a team where each individual is striving to be the best.  If each team member can work within an environment or “operating structure”  such that they are able to realize their full potential (i.e. she/he is involved and engaged) and reach a state of “flow” (self-actualization), the collective team will ultimately build enough positive momentum to virtually guarantee project success.” – Adrian Daniels

A little over a year ago, I wrote an article that discussed how Abraham Maslow’s Hierarchy of Needs could be employed in other paradigms other than pure survival.  One such paradigm is the use of this hierarchy in project management.

Project management is a discipline that is more complex than a process or project plan.  Remember, people = complexity.  Understanding what motivates individuals to go “above and beyond”  and mastering team dynamics is what differentiates truly successful projects from average ones.

The concept that I’ll cover in the next several posts is intended to help project managers and participants really understand the interpersonal aspect to project management.  If you envision project management as a scale, the process and core “plan” are ultimately balanced by the interpersonal / psychological concepts described here.

As you take a closer look at this project management hierarchy, think about how this structure can be employed in your project(s) (or in ones that you participate in).  Can you employ the entire hierarchy or just elements contained within?  If you were to alter the ordering, what would it look like and why?

The benefits of using this hierarchy are limitless.  By taking advantage of this paradigm, I am confident that you, your team members and your project will  benefit.

Comments Off on The (New) Hierarchy of Needs – Part I

The Project Survival Kit

Jul 10, ’10 9:55 AM

If you were deserted on a stranded island, what three things would you take with you?  While there is no official answer to this question, you could answer this question by identifying the core fundamentals of survival – essentially, food, water and shelter.  If your three things address these needs, you have a good chance of survival.

A similar stance can be said for project management.  All too often, managing a project introduces specific processes, tools, documentation and applications all of which are designed to streamline the act of project management, but may do the complete opposite in enabling true productivity.

I believe that there are three things one needs to have at her/his disposal to accomplish a specific task with a discrete number of resources.  These three things can be thought of as the “project survival kit” – their collective use allows one to “get the job done.

1. Description of the end-state – This 1-2 page document is an expansion of a traditional “scope” statement.  It provides a full picture of the project including artifact creation, team dynamics, communication plans and final deliverables.  The intent is to describe the “ideal” project in sufficient detail before you start working.  Think of it as your “map” to your destination.

2. Team Strengths and Personality Inventory – You have resources at your disposal, but how do you utilize their talents in the best possible way?  Know the strengths and personalities of your team members!  When the relationship is strong, anything is possible.

3. Organizational Chart – If you don’t know how project participants are “linked” to one another, your effectiveness as a project leader will be limited.  In addition, you run the risk of “crosstalk” (redundant and inefficient communication) between project participants which can impede progress.  Also, if there is more than one leader identified on the chart, you have a problem.

So, what am I leaving behind?

You’ll notice that I don’t have a timeline or project plan listed.  While I think a timeline is useful, I don’t think it’s one of the top three.  If you know what you are looking to accomplish, have a good sense of how the team will be organized to deliver this end-state, and their strengths, the project will move forward at it’s most efficient pace; a timeline isn’t going to matter.

I also don’t have risks identified.  Remember, anything can happen.  Even if you list all of the risks you know about, there are plenty of things that you likely don’t.  Spend your time on what’s happening now. If an issue exists, take action.

To be clear, I am not suggesting that you completely eliminate the use of supporting documents or forgo the use of a project plan if it provides a real benefit.

However, by looking at projects with a forward-thinking mindset, I think you’ll be less concerned about timelines, documentation, “CYA” strategies and risks / issues inventories.  Instead, you’ll be utilizing resources whose activities are all designed to achieve the end-state in the most efficient and enjoyable manner possible.

It’s about focusing your attention on the activities that truly matter, and isn’t that what getting things done is all about?

Comments Off on The Project Survival Kit

The Crystal Ball.

Mar 12, ’10 1:57 AM

“Begin with the end in mind” is based on the principle that all things are created twice. There’s a mental or first creation, and a physical or second creation to all things. – Stephen Covey

One of the many things I’ve learned in project management is that “starting with the end in mind” is one of the best methods to ensuring a successful outcome.  When your team has a clear sense of what need to do from the beginning, task definition and assignment activities come naturally and the team is able to spend more time focusing on the “day-to-day” issues vs. continuously wrestling with an ever-changing scope definition.

A similar approach can work extremely well when envisioning your future.

An article in the Futurist magazine entitled “Envisioning your Future: Imagining Ideal Scenarios” suggests that:

… having a vision is to be an idealist.  This idealism should not be confused with unrealistic ideas; it should be used synonymously with having “a standard of excellence”.  A person that is by nature a visionary looks into the future as though it is filled with possibilities, not probabilities.

If I look at my future based from who I really am, and document a clear description of what that future looks like, my life starts to become what I’ve created for myself.

After much thought, I came up with the following personal vision:

“My vision for the future is comprised of positive experiences that intertwine my ‘personal’ and ‘professional’ lives into a single life structure.  Because of this, the long-held notion of “work-life” balance is lessened, and at its extreme, no longer required.  By thinking strategically, I am able to spend my energy on activities that pay dividends over both the short and long-term.  A continuous and purposeful stream of explicit and implicit challenges allows my mind to expand at an accelerated rate.  With this expansion comes possibilities, and possibilities spark further action towards an ideal state called “Ultima”.  My relationships are continuously expanding, but only at a rate where the relationships themselves are developing at a natural and lasting pace.  My ability to see the unique qualities of each person and strive towards relationships that are, at their core, genuine, helps build strong partnerships that ultimately become central figures in a life structure built around growth, energy, complexity, awareness and intensity.”

Fortunately, I think this is fairly representative of what I want my future to look like.  The next step is to take this concept and apply it to my design firm.

What does my business vision look like?  I’ll talk about that in my next post.

Comments Off on The Crystal Ball.

The Hierarchy of Needs.

Jun 27, ’09 2:40 PM

In one of my earlier posts, I discussed the concept of “Flow” and how the key to achieving flow – and ultimately happiness – is being able to live a life filled with involvement and enthusiasm in all areas.

In retrospect, is this reasonable given that one’s life circumstances aren’t necessarily such where “happiness” or “flow” is the primary focus?  For example, if my house recently burned down, my primary focus will be on finding immediate shelter – not on being “enthusiastic” or “engaged”.  My focus in this situation is survival.

As you can imagine, there is an ordering of needs that needs to be understood.  Such an ordering – the Hierarchy of Needs – was devised by psychologist Abraham Maslow in his 1943 paper “A Theory of Motivation”.

“Maslow’s hierarchy of needs is predetermined in order of importance.  It is often depicted as a pyramid consisting of five levels: the lowest level is associated with physiological needs, while the uppermost level is associated with self-actualization needs, particularly those related to identity and purpose.  Deficiency needs must be met first. Once these are met, seeking to satisfy growth needs drives personal growth. The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are met. Once an individual has moved upwards to the next level, needs in the lower level will no longer be prioritized. If a lower set of needs is no longer being met, the individual will temporarily re-prioritize those needs by focusing attention on the unfulfilled needs, but will not permanently regress to the lower level.” – Wikipedia

The hierarchy – represented in the form of a pyramid – has the following structure:

– Self-actualization
– Esteem
– Love/Belonging
– Safety
– Physiological

As just mentioned, in this hierarchy the higher needs come into focus only when the lower needs are met.  Thus, the house example presented earlier makes sense given the ordering shown here – i.e. I need to be safe before I can really focus on my long-term goals, etc.  The key is to ultimately address “core” needs such that one can realize her/his fullest potential through a “self-actualization” phase.

This “hierarchy of needs” concept is applicable in other disciplines as well.

For example, in the book “Universal Principles of Design“, the “Hierarchy of Needs” is one of the 210 design principles described.  The specific use of this hierarchy shows how a given design “…must serve the low-level needs (e.g. it must function), before the higher-level needs, such as creativity, can begin to be addressed”.

This particular implementation of the hierarchy of needs looks as follows:

– Creativity
– Proficiency
– Usability
– Reliability
– Functionality

Having some experience with the design lifecycle, this makes complete sense.  An iPod that looks nice but breaks after the first two months clearly isn’t a good design.  The authors recommend using this hierarchy as a “report card” of sorts to determine where modifications should be made to existing designs to further improve them.

Another discipline where this concept is useful is in the project management arena.  Having considerable experience in this space, I was puzzled with the absence of “interpersonal” elements in project management literature given that the team is ultimately the core of any successful project.  To this end, I formulated a hierarchy of needs that incorporates pure project management concepts along with core interpersonal elements.

This hierarchy looks like the following:

– Momentum
– Problem-Solving
– Constraints
– Storytelling
– Constraints
– Foundation

The key behind this structure is that it has a very close relationship to Maslow’s original hierarchy of needs.

The “real” goal of any project is to have a team where each individual is striving to be the best.  If each team member can work within an environment or “operating structure” (the layers listed above) such that they are able to realize their full potential (i.e. she/he is involved and engaged) and reach a state of “flow” (self-actualization), the collective team will ultimately build enough positive momentum to virtually guarantee project success.

Full details about each of these layers will be published in early July 2009.

The thing to remember is that this hierarchy concept can be employed in many other disciplines – not just the three described here.  Think about how a “hierarchy of needs” can work within your particular discipline.  What is the “ultimate” objective / goal?  How can you use this hierarchy to measure not only your performance but others that also rely upon this structure?

Comments Off on The Hierarchy of Needs.