Ultimus Releases BPM Prioritization Tool February 15, 2009Posted by Darth Sidious in Business Management, Project Management.
add a comment
Ultimus announced an interesting tool aimed at helping organizations prioritize what processes to automate, based on the value it presents to the business.
Ultimus, a maker of business-process management (BPM) and workflow-automation software, announced the released of a Microsoft Excel-based application designed to help organizations select and prioritize which business processes to automate.
The tool guides the process owner through a systematic approach to automation goals, ranks the suitability of choices, and determines which are most likely to provide the greatest benefit to the organization, said the company.
For more information, read on…
Cost of Changes vs. Risk and Uncertainty January 23, 2009Posted by Darth Sidious in Project Management.
1 comment so far
Now and then I keep an eye on some interesting management/leadership/project mgmt blogs.
This interesting post came up on an aspect covered in the upcoming PMBOK V4 (Project Management Book of Knowledge).
In the article they related how Cost of Changes, Stakeholder Influence, and Risk/Uncertainty change throughout the life of the project. They compare how in traditional approaches a project starts off with a high degree of stakeholder influence and low cost of changes – but as the project matures, cost of changes sky rocket, and stakeholder influence drops off quickly.
The stakeholder influence drops off quickly in such scenarios, because in all-or-nothing super-size projects, once the snowball starts rolling you invest so much that you’re unlikely to abandon the work.
So they’re saying the cost of changes can be flattened out, and the risk/uncertainty reduced by using agile/iterative development, while at the same time stakeholder influence can remain relatively high by being able to constantly adjust priorities.
I also liked the thought of this:
“Iterative methods deliberately pull high risk elements of projects forward in the timeline to tackle them early and reduce their impacts. By undertaking the risky work sooner we have more options, time and money at our disposal to solve them or find work-arounds.”
Is Your Project Charter Still Valid? November 2, 2008Posted by Tariq Ahmed in Project Management.
add a comment
A Project Charter is a document that states the reasons for doing the project, objectives of the project (scope), and identifies the stakeholders. I don’t want to discuss the details of a Project Charter, but rather the importance of making sure it is still valid as you work through a large project. The bigger the project, the longer it will take and the more resources it will consume. Time is your enemy in these cases, as time can cause drastic changes in the company, economy, management and competition, which can cause your project charter to become out of touch. When this happens, the project runs the risk of being cancelled completely.
A sound Project will have an ROI analysis, which should have justified the project to start with. This should include assumptions such as:
– We have resources allocated for the project.
– Other projects are not taking our resources.
– Future projects aren’t threatening our resources.
– Competition hasn’t pressured us in a different direction.
– Top management still wants the project completed.
– Management is comfortable and aware of the timelines.
– The company’s financial situation hasn’t changed.
– Economic conditions are stable.
– The company is still in X business.
– Our initial ROI analysis is still valid.
These assumptions should be checked on a regular basis with the stakeholders, including top management. Many stakeholders may be squeamish to bring this up, as the questions create doubt and may sound negative. The PM and stakeholders may be so absorbed and emotionally attached to their “pet project”, that challenging the assumptions and ROI is treasonous and will get you executed or the very least shunned upon.
In order to combat this, as a PM or stakeholder, this Project Charter Revalidation process should be part of the project plan, per company policy so everyone is aware that these tough questions will be asked on a scheduled basis.
Successful Projects October 23, 2008Posted by Tariq Ahmed in Project Management.
add a comment
PMI, Six Sigma(?) and similar institutions will teach you the basics of Project Management. They’ll discuss concepts like: project scope, tasks, work breakdown structure, dependencies, resources, costs and project plans. Theory is great, and all of those things will help your project. But what happens when the 800 pound gorilla rears it’s ugly head? I’m talking about politics. Politics can destroy a project faster than I can electrocute someone. In the coming weeks we’ll discuss the ugly side of projects. The things they don’t teach you in school.
Quit whining about the problem and move on… September 18, 2008Posted by Darth Sidious in Business Management, Project Management.
You humans suffer from this disorder of pepetual complaining about the problem. Yes, projects, initiatives, or whatever do encounter hurdles and it’s part of the process to identify problems that come up.
Though what tends to happen is a constant restating of hte problem in various differnt forms, and this part is more of a psychological/emotional process of getting it out of your system.
- Flip: “Had Jeff done more analysis, we wouldn’t have gone the AJAX route and instead used VaderSoft Silverlight for our RIA applciation.
- Flop: “Ya, the application is dirt slow… it takes forever to do a search and pull up all the rebel bases where Jedi’s might be hanging out…”
- Flip: “That’s the problem with AJAX… all that XML over the wire…”
- Flop: “And Jeff, he can’t see two steps ahead…”
That can go on forever. Ok, Jeff didn’t do enough analysis, and the wrong technology was used. Problem identified, now it’s time to move on and start talking about solutions.
Scope Creep – The bane of projects September 8, 2008Posted by Darth Sidious in Project Management.
add a comment
Whether it be software development, mechanical engineering, or construction… scope creep is a project manager’s kryptonite (btw the Empire has a sale on kryptonite if you need to take care of any of those do-gooders from the planet Krypton).
Earth’s United States military program requires extreme levels of planning and scoping, every nut and bolt is accounted for in their project plans. Yet… even that isn’t enough to control scope creep. E.g.:
- Virginia Class attack submarine.
- Scoped: $57 400 000 000 over 11 yrs
- Actual:$81 300 000 000 (ya, that’s 81 billion)
- MQ-9 Reaper (unmanned aircraft drone)
- Scoped: $690M over 3 yrs
- Actual: $2.2B
- V-22 Osprey (vertical take off plane)
- Scoped at $38B over 20 yrs
- Actual: $54B
Although we’ve recommended many ideas, one idea is to implement continual measurement. For example, when engaging in a project at the start, keep constant track of estimated vs. actual target dates and costs – and you need to have a plan in place where if a threshold is crossed management decides to cut their losses and can the project.
Continual improvement through post mortem’s August 22, 2008Posted by Darth Sidious in Project Management.
A lot of organizations move at a frantic pace (especially the Galactic Empire), but never really improve. When it comes to projects and managing projects it’s common to move right onto the next one as soon as one is done.
Because of that, are you ever truly improving? It’s worth it to add as part of the project plan to factor in a post completion post mortem. In the post mortem you’re looking to identify the following…
What did we do well?
Being fully aware of your strengths is important, as that’s what you want to continue leveraging as an advantage going forward. Are you particularly good at completing certain types of projects, actualizing certain types of ROI, or taking on certain kinds of hurdles?
When it comes to prioritizing future projects, it would be a smart move to notate somewhere for all future projects how well your strengths (from the perspective of project execution) map against the project as part of the evaluation process.
For example the Empire is particularly good at building Star Destroyers, we can pump those suckers out like it’s nobodies business. Since resources (people, capital, and time) are always in short supply and we have a need for a Star Destroyer, vs. something else – each of which are equal in priority… the tipping balance would go in favor of the Star Destroyer since we know we can kick ass in that area.
What didn’t we do so well at?
This is where the improvement comes into play. If you’re not identifying what you didn’t do so well at, you’re going keep repeating the same mistakes over and over again. For example there’s a mistake that the Empire keeps doing and it drives me crazy – we keep using the same round interface port design that allows R2D2 to keep overriding our security systems (you have no idea how annoying that is).
As part of the post mortem list out all the things that didn’t go well with the project. Things you didn’t anticipate, what caused certain delays, why budgets were overrun, why the amount of scope creep was out of control, things you found the organization isn’t good at, etc… For example I’ve found that the Empire is not good at building commodity low cost attack robots; Jedi’s are able to walk through armies of those as if they’re nothing more of a nuisance than flies. We just can’t get the artificial intelligence level high enough with the low cost CPUs, part of that is our coders lack the skill to write efficient enough code (I’ve electrocuted them as a result btw).
So going forward now that we’ve identified that weakness at least we’re not going to keep making the same mistake. Though in those analogies they’re slanted towards the quality of the product, but just to clarify, your focus is on the project and not necessarily the product. A bad product is just the result of not identifying our weaknesses up front as part of the project planning (e.g. I like the idea of cheap robots, so if we try to do it again perhaps we bring in a company that specializes in such things).
Why do most projects go over budget? May 31, 2008Posted by Tariq Ahmed in Project Management.
add a comment
Whether its time, money or both, very rarely can a project meet its initial budget estimates.
Consider our latest Death Star project. It took the Emperor and myself to personally over see the construction to keep it on track. Even then we had to sacrifice 30% of it to get the main weapon on-line, much to the surprise of the rebel scum.
On Earth, the U.S. Air Force in 1986 estimated the B-2 Stealth Bomber would cost 437 million per plane. By 1994 the cost ballooned to 2.2 billion per plane.
Why do organizations have so much difficulty calculating project budgets and sticking to them?
Difficulty estimating costs: Many costs may be unknown when estimates are drawn up. Requirements may not be completed or the project involves outside vendors who give unrealistic estimates.
Requirements are never fully scoped out: Requirements are set out, but no one asks the tough questions to bring the requirements from 50% to 100%. The larger the organization, and more departments that are involved, the more difficult it becomes.
Change occurs: Unforeseen consequences/new events can drive up the costs and time frames. The most noticeable agent of change is scope creep. Scope creep can occur for many reasons including the will of individuals, incomplete requirements, new requirements or unforeseen consequences. To control scope creep, always label new requirements as “must haves” and “nice to haves”. All “nice to haves” should be pushed to a Phase 2, which may or may not occur.
All project phases aren’t included: Ending phases of the project may be considered by some to be a “separate project”, a “future project”, or “routine maintenance” and therefore is excluded from the original project estimate.
Under-budget on purpose: The costs/timelines are purposely set low in order to get a project approved, knowing full well that reality will cost more and take much longer than our estimate. Everyone wants their project to get the green light. Consciously or sub-consciously we low-ball everything. Who wants to give their management “reality”? If you did that, it would never get approved. Just lie, and we’ll make up excuses later on why it’s over-budget. Once the company has committed/spent resources on it, they can’t back out.
Of course history is full of projects that went out of control and the plug was pulled. The politics of under-budgeting on purpose is very complicated indeed.
The best measure of a future project is to look at past projects and their initial budgets and final budgets. History tends to repeat itself.
The golden rule is “take your estimate and double it”. Is that enough?
Deadlines April 29, 2008Posted by Tariq Ahmed in Project Management.
Deadlines, target dates, call them what you will, but every project has dates and deliverables. When deadlines are tight, I often see underlings commit to a date, and when that date arrives, they quick add the infamous caveat “Monday… end of day Monday”.
Monday becomes EOD Monday, which then becomes midnight, which then becomes Tuesday morning and so on.
A company should have a unified policy as to what due dates mean. The 1st, doesn’t mean end of day, it means that morning. It means the deliverable is ready for demonstration, testing, release or whatever the case may be.
Identify the Owner January 1, 2008Posted by Darth Sidious in Managing Employees, Project Management.
1 comment so far
You’ve heard the saying, “Too many Sith Lords in the Command Ship”, I think you earthlings have a similar saying of “too many chefs in the kitchen”.
Collaboration is great, and should be a natural part of your organization’s culture – but issues and confusion will arise if owners of areas aren’t clearly defined.
Whether it’s fighting a crisis, issue resolution, routine tasks, domain areas, to projects – there has to be ONE owner. Otherwise it’s unclear where information ultimately needs to flow up to, and what the chain of decision making needs to be.
Is your technical staff on-call? What if that pager goes off, but it’s not in that persons particular area of ownership or expertise? The person on-call is the owner – the owner of the alert, and they have the power to rope in the subject matter experts needed, and/or the owners of such areas. Ultimately the resolution of that alert is theirs.
On a Project, there has to be a single-owner. Don’t confuse this with sponsors and supporters of the project. The owner of the project is ultimately responsible for getting the project done.
Do you have a Database team? There has to be someone who owns the maintenance plans, data architecture, schema design, database change policy and processes, etc… It doesn’t mean they have to come up with all the ideas, and all of it could be the result of the team collaborating on what the best practices need to be. And it doesn’t mean they have to do all the work. But the owner is responsible for making sure that that collaboration occurs, gets documented, and somehow enforced.
When fighting a business crisis or a technical one – make sure the owner is clearly defined. Otherwise people are going to naturally float decisions up their management chain, it won’t be clear whose making the decisions in the first place – so you get this decision confusion that results in latency as everyone tries to sync up on who decided what.