Project Management Life Cycle

Illustration: Project Management Life Cycle

We all know that IT projects don't just happen. They usually start with an idea that gets socialized internally, until somebody decides it is interesting enough to write a business case, justifying why the idea might be good for the Enterprise. The Project Management Life Cycle (PMLC) walks the reader, from left to right, through all the components of a project. It assumes the project has been instantiated and has executive sponsorship. Other activities prior to the project itself include the Opportunity Assessment, a Cost/Benefit Analysis, and likely ROI and TCO studies.

The PMLC illustration above is designed to show three things at each stage: the roles that contribute to the project, their responsibility and their deliverable. Starting on the left, the Stakeholders typically sit on a Steering committee, and provide budgetary approvals for the project.

The project is run by the Project Manager, who is responsible for budget, timeline & resources. They usually draft the Project Charter, which defines the objectives and scope of the project. They are responsible for reporting back to, and taking direction from the steering committee. It is their responsibility to deliver the project to successful completion.

The Business Analyst does a lot of leg-work, dealing with the stakeholders to understand requirements, both functional and non-functional. They will take raw data they have collected, and produce information which is valuable to the project, and consumable by all members of the project team.

Now that you have a general idea of the flow, you can interpret the rest of the illustration for yourself. Other information that will later become key is called the RACI. It is an artifact that names all of the roles (as seen in the illustration), and determines who is Responsible, who is Accountable, who is Consulted and who is Informed when a project decision has to be made.

This is a general look at how IT projects move through their life cycle. In a future post, I'll overlay the CLAP Framework, to pull together all of the concepts into a single view.

Posted with Blogsy

SMART Goals

When setting Goals, there is a great model to follow that will help in achieving them !

 

 

S - needs to have enough detail.

M - needs to have actual metrics by which to measure success

A - needs to be something that is possible to achieve

R - if the goal doesn't have any purpose, what's the point ?

T - needs to have a due-date to work towards

 

 

A good example of a SMART Goal would be: "I am 240 lbs today. I want to get my weight under 200 lbs by Christmas."

 

 

Posted with Blogsy

How to Achieve Your Goals - the ERRC Canvas

Illustration - the ERRC Canvas

 

As you might already know, I love canvases. They provide a simple means of communicating ideas. The image at left describes a very basic canvas to convey a very powerful idea: What do I have to do to achieve a Goal ?

In another BLOG entry, I will discuss Goals - specifically what makes good goals vs what makes difficult goals. If you want to do some homework, in a future BLOG I will discuss SMART Goals and why they are effective.

In general, and especially true in Business and IT, Goals can be achieved by placing tasks into one of four broad categories - Eliminate, Reduce, Raise, Create. Let's take a closer look at these simple yet powerful concepts. But remember, Goals are only important as a means of realizing a Strategy. Often, strategies are realized through the successful completion of a number of goals. Equally, there may be more than one Strategy being realized !

Eliminate - this is a pretty straightforward concept. Ask yourself the question "What do I need to remove from the environment to achieve the Goal ?". It could be simple, like lets eliminate duplicate services. If two systems can service the same Business Activity, then one of them is redundant. Ergo, one of them could be eliminated & help achieve the Goal.

Reduce - this is also a simple concept. If the Goal is to "decrease server sprawl", then the use of a consolidation solution (think of server virtualization) would reduce the number of physical compute hosts required to service the the Business Activities. Implementing server virtualization reduces the number of server's required to host the workloads, realizing the Goal.

Raise - this often goes hand-in-hand with Reduce in that often reducing one element will raise another. In the above example, we looked at implementing server-virtualization as a means of reducing server sprawl. It also has the opposite effect of raising the rate of physical server utilization !

Create - This is the tricky one. What do I have to ADD to the environment to achieve the goal ? Fortunately, the context of these canvases is around achieving IT Goals, in alignment with Business Strategy. So you might create a new process for deploying the virtualized servers into the compute environment, perhaps to enable a new Business Activity.

Now, each one of these sections of the canvas can contribute to the overall goal, meaning you might have many entries in each quadrant, all in alignment to the goal. This helps develop a list of activities which might need prioritization & dependency-mapping in order to complete. But at least now you have a defined method of achieving the established goal !

 

Posted with Blogsy

CLAP Framework for IT

Many Enterprises struggle with IT frameworks. These frameworks are meant to help turn Business strategy into executable plans. Some frameworks, such as TOGAF or Zachmann will help an Enterprise IT group understand WHAT it needs to do to achieve its goals. Other frameworks, like COBIT or ITIL will further explain HOW to achieve those goals. When an Enterprise does not follow any of the established frameworks, they will often try to devise their own. The diagram above illustrates one such framework - the "CLP" framework (the "A" was added later, after missing information was identified).

Conceptual - this stage of the framework takes the Business Activities into account. Each discrete activity can be mapped out as a few elements in a process, describing a single activity. An example might be "calculate price".

Logical - this stage maps the discrete activities required. To calculate price, we need some information from a number of sources, such as the gross price, a taxation rate, a discount and a profit margin. Further, architectural governance (standards) are applied, such as use of a Linux operating system, or mandating a particular security framework. Finally, Non-Functional Requirements (NFRs) are described, such as how quickly a system must respond or how many transactions per minute the system must satisfy.

Application - this stage is where we begin to apply some business logic about what to do with the information. It maps out what the information should be expected to look like, such as expressing numbers in Currency notation, with two decimal points of precision. It will also describe any user interfaces and other means of accessing information. It specifically maps business activities to Functional Requirements.

Physical - this final stage helps identify all of systems that are required. Items such as CPU utilization and storage requirements are calculated to determine how best to implement the system into a computing environment. It describes systems interactions in terms of protocols and transports.

This is not an exhaustive look at frameworks, and many Enterprise Architects will keenly assess missing elements from this simplistic framework. But, executed properly, a framework such as this one could be sufficient for an Enterprise to begin taking advantage of IT to realize their business strategy.

Posted with Blogsy

P.O.W.E.R.

Lately I've been building a lot of models. As many may know, my role at my company is a mix of Enterprise Architecture and Technology Strategist, with project work to keep me busy. I spend the majority of my days working out how improving various technology systems relate to real business goals. I like to think my work provides information that supports good business decisions.

Sure, there are many different frameworks one can apply, such as TOGAF or Zachmann. But in the real world, few organizations adopt the entire framework. They take a smattering of TOGAF and a little of ITIL, then build out projects based on Waterfall or Agile project management methodologies. Finally, they bundle all that up & call it their "process". In my many roles in this industry I have seen how well this works - or doesn't !

 

A friend of mine has challenged me to write about how I have been successful using an adapted model, and how to re-apply that model to other Enterprises. I sought his counsel on how to go about doing that and he introduced me to a very simple (hence very elegant) writing method: P.O.W.E.R.

P - Plan: what are you writing about ? Who would the target audience be ? What style of book should it be ?

O - Outline: build out an imaginary table of contents. What should be included ? In what order ?

W - Write: simply go about the business of collecting your ideas on your word-processing application.

E - Edit: word-smith. Play with sentence structure. Play with the order of your ideas. Hack & slash as needed.

R - Release: it'll never be "perfect", so when it is good enough, stop. Publish. Think about the next book !

It's a simple yet powerful (you see what I did there ?) way to begin the process.I think I'm going to take a stab at it, and see what happens. But don't expect to see my name on the NYT Best-Seller list - it'll be a technical/architectural manual, so it might only appeal to a limited audience.

 

Posted with Blogsy