What a great tool TaskSwitchXP is.
I found it after watching Scott Hanselman over at www.groktalk.net. Scott was talking about his 10 favourite tools…in ten minutes. The groktalk is here.
And there are plenty more “10 minute” GrokTalks available for you to stream or download…enjoy!
[Update] Scott has some other really cool recommendations.
This posting over at ScottishDevelopers got me thinking, especially since I’ve used Excel and Word from a number of Delphi applications over the last eight years. I have come across this problem in the past (Win32), so I thought it should be fairly easy to chase.
After a bit of research, The Code Project suggested that the Excel process be killed off through code:
Process[] pProcess;
pProcess = System.Diagnostics.Process.GetProcessesByName("Excel");
pProcess[0].Kill();
Well, that would work, but it might kill off the wrong instance, or kill off the user’s precious ‘expenses’ spreadsheet instead of the one we created.
To help me trace the problem, I used the following code:
using System.Diagnostics;
using System.Runtime.InteropServices;
Excel.Application excelApp = null;
Excel.Workbook excelWorkbook = null;
Excel.Sheets excelSheets = null;
Excel.Worksheet excelWorksheet = null;
Excel.Workbooks excelWorkbooks = null;
private void button3_Click(object sender, System.EventArgs e)
{
excelApp = new Excel.ApplicationClass();
excelApp.Visible = true;
excelWorkbooks = excelApp.Workbooks;
excelWorkbook = excelWorkbooks.Add(System.Reflection.Missing.Value);
excelSheets = excelWorkbook.Worksheets;
excelWorksheet = (Excel.Worksheet) excelSheets.get_Item(1);
excelWorksheet.Cells[1,1] = "42";
}
private void button4_Click(object sender, System.EventArgs e)
{
excelWorkbook.Close (false, System.Reflection.Missing.Value,System.Reflection.Missing.Value) ;
excelWorkbooks.Close();
excelApp.Quit();
Marshal.ReleaseComObject(excelWorksheet);
Marshal.ReleaseComObject(excelSheets);
Marshal.ReleaseComObject(excelWorkbooks);
Marshal.ReleaseComObject(excelWorkbook);
Marshal.ReleaseComObject(excelApp);
excelWorksheet = null;
excelSheets = null;
excelWorkbooks = null;
excelWorkbook = null;
excelApp = null;
GC.GetTotalMemory(false);
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.GetTotalMemory(true);
}
This code creates an Excel application, populates it, then lets us close it. Invoking the button3 code creates it, button4 removes it.
Now, without the calls to the garbage collector, excel.exe hung around if the code behind button3, button4, button3, button4 is invoked.
In the short-term, I would suggest adding the additional calls to the garbage collector (although, and this confirms it, memory reclamation is not guaranteed). It’s time to read up on the garbage collector and COM Interop.
I used Visual Studio 2003 and Office 2003 to test this.
Technorati Tags: Excel, InterOp, Kill Process, C#
I have a friend who is looking for a job in IT, imagine his surprise when he searched for “IT”…
I particularly liked jobs 12 and 13…
Isn’t it amazing how fate throws people together and from that into conversation?
Today, I found myself standing in front of the flight departure monitors at Gatwick airport (I had actually managed to drop my bottle of fizzy drink and was waiting on the cleaning bloke to mop it up…which he did and then left a yellow sign with a slippery surface logo on it…)
Anyway, I digress: a gentleman walked up to me and asked “Do you know where gate 18 is?” Part of me just wanted to say “yes”, but that would have been rude, albeit somewhat French/Parisien in its humour content (Sorry Alex!). But, before I could tell him that it was “over there, follow the big yellow signs”, he walked off…leaving me in eye contact with another gentleman who saw and heard the whole thing happen! Some humour about the situation followed…and we exchanged the usual pleasantries that one does with fellow airline passengers.
As it happens we ended up walking down to gate, briefly chatting on the way. Gate 10 wasn’t far away, it’s marked as a 10-15 minute walk I think, but it really only takes 5-6 minutes. We arrived at gate 10, along with a few others, only to be told that the Edinburgh flight wasn’t departing from gate 10, the Shannon flight was. Of course, the lady on the security desk was positive (and nice about it too) and made a telephone call on our behalf. Long story, cut short, we were departing from gate 12 instead. Now, being a frequent flyer, and one who listens to the safety briefing at the start of each flight (!), I figured that there was a delay. The time it would take us to get from gate 10 to gate 12 was roughly 10 minutes, more if you were a member of the original 10-15 minute fraternity…this would buy the airline some time! Now, easyJet have been very good, flights have been on time, etc. so neither of us were particularly worried about the faffing about.
Anyway, it turns out that this gentleman with whom I exchanged plesantaries owns and publishes a number of magazines: Spain Magazine and a couple of others (I know the names, but can’t find a web-site just yet). And he’s an actor: remember the parrot in the Scotch (now 3M) TV commercial? He did the yawn…and yes, apparently parrots don’t yawn, but that’s showbiz!
We landed on time at 2025…20 minutes into the flight the first officer announced that they’d made a couple of “left turns” and shaved 10 minutes off the delay…amazing 🙂
Oh, and Rt Hon the Lord Steel of Aikwood KT KBE DL was only a couple of rows behind us…sadly the first things that came to my mind and that of my travelling companion was the Spitting Image sketch where the two Davids (Owen and Steel) discussed the merger of their two parties (Social Democratic Party and the Liberal Party), to form the Lib Dems. The name change change wasn’t much for David Owen, but for David Steel’s party, it was! Anyway, it was funny at the time 🙂
I’ve spent the last two three weeks reading through Scott Berkun‘s first book, The Art of Project Management.
It’s an excellent read, I’ve reviewed it for the folks over at Scottish Developers.
If you would like me to review your book, either like this or prior to publishing, drop me an e-mail via the address found at the bottom of CraigMurphy.com.
Many projects fail (are shelved, go over budget, over schedule, suffer serious scope creep, suffer serious scope “minimalisation”, etc.) because of inappropriate decision making.
Inappropriate covers a whole multitude of common mistakes, such as:
Inaccurate decisions
It’s fair for a project manager to expect some support from the project’s stakeholders and any person or group who may have information to offer. We might refer to these persons or groups as centres of competence, i.e. folks who know a thing or two about how part of the project should work. For example, if the project required a list of activities that we could charge expenses to, we might expect to go to the payroll (or possibly human resources or finance) function and request it from them.
An inaccurate decision is one that the original centre of competence believes to be 100% accurate in their eyes, but is actually somewhat out-of-sync with what occurs in reality. Unless the project manager has domain-specific experience, it is unlikely that he or she will be able to spot an inaccurate decision (even with rigorous testing, inaccurate decisions will slip through the net).
Inaccurate decisions usually surface during an examination of workflow. The most common workflows through a project or system will be clearly defined, workflows that are specific to a small number of individuals or have special-case processing and calculation behind them, are typical candidates. Fortunately, if inaccurate decisions are caught early, their impact can be prevented from reaching project completion where the cost to rectify the inaccuracy is significant.
Luckily, if the project team is domain-aware and inquisitive, such inaccuracies may be surfaced through the use of a bottom-up analysis of the workflow and the decision. This involves the project team taking a pro-active role that plays the part of a “what if” analyser. Each step of the workflow is examined and the decisions that have been made are applied. Often this step will involve the use of mock-ups or worked examples that highlight the inaccurate decisions. The mock-ups and worked examples serve a second purpose: they can be used to invoke discussion that leads to the correct decision being reached. If this activity requires that a user of the said workflow is brought in to assist, so be it: they may have more questions that cause the decision to be invalid rather than just inaccurate. It’s better to let an decision become invalidated rather than assume that “it’ll come out in the wash” – this never happens, things always get worse rather than better.
Untimely decisions
These are less common. Such decisions are made too early in the project and are often geared up to get ticks in boxes or to endear decision makers to the project team and others outside of the project team (“Look at me, I’m co-operating on “high-profile” project”). In reality, early decisions are often revisited downstream as the circumstances surrounding the original decision and the question that prompted the decision to be made, change considerably.
Decisions that are made too late, i.e. after the fact, are just as bad. Not just because they are late, but because invariably a project assistant, a secretary or even a project manager have been repeatedly trying to get the decision made…and this will involve wasting a lot of time visiting the decision maker, e-mailing the decision maker and possibly even going to the decision maker’s upstream line manager (which does the project morale no good whatsoever). By virtue that time is being consumed chasing the late decision(s), the project schedule takes a hit as it is wasted resource (they’re not concentrating on moving the project forward).
Overruled decisions
Sometimes the simpler decisions are no-brainers and are often made by the project team on the premise that the decision maker will simply agree with their choice. The kinds of decisions we’re looking at here are the blindingly obvious ones. For example, a decision regarding XYZ has to be made. There are three possible choices for the decision maker to evaluate, however in reality only one will ever be acceptable: the obvious answer.
Despite their simplicity and their obvious answers, the decision maker steps in and overrules the obvious answer with one of their own. Sadly, this egotistic approach is often to the detriment of the project. A useful salt test for this scenario is for the project team to select the obvious answer and condemn one of the other obviously incorrect answers. The decision maker often homes in the condemnation and puts the incorrect answer forward as their decision. The time required by the project team to backtrack and undo an overruled decision can be considerable, invariably the project schedule takes a hit.
Conflicting decisions
In my opinion, these are the worst of all. These are decisions that give project managers a false sense of progress, they are decisions that allow ticks to be put boxes, near term work plans to be updated and the next set of tasks to be considered.
It’s only later that the real truth is discovered when another person or group provide their decision, only for the project manager and the two (or more) parties to realise that a conflict exists. Typically the conflict arises as a result of an uninvited person or group volunteering the decision or information surrounding the decision. At least with the conflict out in the open something can be done with it: we should therefore be grateful that an unsolicited conversation has resulted in the surfacing of a project impediment.
However, there are times when a conflicting decision arises because there are too many domain experts or too many stakeholders wishing to exert their influence on the project and its outcome. This is more commonly described using the phrase: Too many cooks spoil the broth… Such a scenario sees much indecision, much argument and much oneupmanship – none of which are good for the project or the sanity of the project team.
In summary…
Decisions really need to be timely and accurate and they need to be made by a person or persons who are qualified to make the decision. The decision maker also has to have the support from the project team, the stakeholders and those outside of the team such that the decision does not conflict and is not overruled. Decisions that affect more than just the person making the decision, such as employees, should be examined with a view to understanding how the decision will be received (consultation breeds acceptance). Decision making processes that demonstrate the first sign of oneupmanship should be terminated immediately and the offending parties advised of their faux pas.
If necessary, create a decision log, but be sure to include at least the following:
And if you do create such a log, make it visible to the stakeholders, the project team and other interested parties. You would be surprised how quickly decisions are made when they are in the public domain and visible to more than just the original decision maker…more so if you’re able to colour-code decisions that are aging decisions.
In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making
Clarke has been lamenting about how so much of his conversation/experience seems to live in his blog – granted Clarke was lamenting to me over a pint, he didn’t actually publish anything about this issue.
However, I am finding that the older I get the more that I have to remember, and since my brain feels like it never stops, I write a lot of stuff down. But recently, I’ve started to add some structure to my thoughts (please don’t laugh) and have a number of blog postings sitting in my drafts folder – you might get to see some of them, you might not.
In May 2004, when I finally arrived in blogsphere, or so I like to kid myself, I struggled for blog content. Now, pretty much a year later, I’m tripping over content. Of course, having content is one thing, finding the time to write it up and blog about it is another. This is especially true as, currently, I don’t blog during office hours.
Similarly, some blog content might not be suitable for public consumption, so now I realise why some colleagues have two blogs: one that is publicly visible, the other that is totally private. Wherever you blog, it doesn’t matter, because when you do blog, the act of writing something down and hitting the save or publish button has the psychological effect of clearing it from your mind. In reality however, it has the opposite effect: it firms the blog posting up in your mind. Well, it does for me at least: your mileage may vary.
With that thought, I am now very much in favour of blogs for project management. Not that I was ever against them, I just hadn’t made my mind up until recently. Blogs are important communication devices, teams can gain access to project specific blogs, publish their own content and generally use the blog to organise the project’s artifacts and facets.
With careful use of RSS, blog content can be pushed to team members. Prioritisation of content can be organised via the frequency at which the project feeds are polled: my RSS aggregator lets me configure the feed polling time on a per feed basis. I have important feeds polling every hour, less important feeds every six hours.
“But”, I hear you cry, “why not use e-mail?”
E-mail is great, but how often have you ended up becoming embroiled in a massive exchange of e-mails over something trivial? Try organising a meeting spread over two or more geographic locations with more than five attendees and you’ll soon find yourself dealing with an in-box full of “I can make the 5th, but not the 7th”, etc. Anyway, this is a deviation from this posting – I’ll be writing more about the proper use of e-mail in one of my project management posts later this month.
Anyway, I’ve said a lot in this posting. I’ve hinted that I’m in favour of using RSS to improve communication, and as I noted here, I will be writing an article about the subject: Using Really Simple Syndication (RSS) To Improve Corporate Communication.
That’s me just finished creating a clean VirtualPC 2004 image with Windows XP SP2 installed.
I made a few copies, mostly all for use with products that are still in beta.
I’m only allowed to tell you about one product that I’ll be looking at and that’s Microsoft Visual Studio 2005.
Expect to see more posts as I spend more time living inside the Visual Studio IDE.
Incidentally, those generous folks over at Scottish Developers have some Visual Studio 2005 beta 2 boxed DVDs to give away, all you need do is attend a meeting or day conference (or if you’re lucky, speak to Craig nicely and he might post one out to you! You must be a signed up member of Scottish Developers though!)
This is an early announcement that I will be publishing a series (i.e. more than one) of posts in the Project Management category.
Each post will cover a specific topic; the first post will cover Decision Making. The posts are my own musings and are based on what I have either seen, been told about, read about or experienced/witnessed (over the last 15 years). Both good and bad issues will be covered.
I might get the order of the topics wrong, however I’m hoping that writing them down will mean they’re not buzzing around in my head – you may or may not be surprised to learn that writing can actually be therapeutic. Once something has been written down, your mind immediately starts thinking about other stuff, well mine does (usually) and since I’m planning a lot of education for June/July, clearing my mind of some thoughts is a good thing.
The first post will appear later this week.
I’ve just finished reviewing TargetProcess for The Delphi Magazine.
TargetProcess is a fully integrated “on-line” tool that aims to help us manage the lifetime of a feature and it does so in four key areas: requirements management, project planning, project tracking and bug tracking. What makes TargetProcess unique from traditional products in this space it the fact that it is centred on “agile” approaches to product development. Agile approaches tend to be iterative approaches, focusing on lots of small product releases as opposed to one major release like those we see with traditional “waterfall” development methodologies.
I was pleased to see TargetProcess offer direct support for Scrum, eXtreme Programming, releases, iterations, user stories, tasks, bugs and time allocation. It goes a long way to help us convince folks who are used to the waterfall model and all the frequently unnecessary upfront planning associated with it, that the flexible world of agile can be managed with the bare minimum number of artifacts and without the need for a fixed project plan. In other words, TargetProcess might help you sell agile to those who don’t believe it works. (Further discussion about “selling agile” can be found here.)
Anyway, you’ll need to subscribe to The Delphi Magazine if you want to read the full review!
Follow the TargetProcess blog here.