Apparently, there is one universal tool that can do all that and is available for virtually all devices and platforms, sometimes even for free. For me it all comes down to using a Google Spreadsheet as a To-Do list. Augmented with some scripting it turned out to be quite useful, supporting automated sorting and coloring.

Preparations

To be able to track tasks in a sensible manner we need to define a couple of columns:

• Date Created: when did the task end up in your inbox.
• Subject: what needs to be done.
• Due to: when does it need to be done.
• Remind me on: when do you want to be reminded that the task is due. This column is especially useful for delegated tasks
• Who: who has the task been delegated to.
• Status: is it open, are you waiting for someone else, is it done?
• Notes: could contain the date of a call you did regarding the task.

You may want to reduce or expand the list depending no your needs.

If you do not have a Google Account create one. Next, create a Spreadsheet document, type the names of the previously defined columns in the first row. To make changing the status easy I’ve created a second sheet and named it “Lists”. It basically holds various status values prefixed by a number to allow sorting: 01 open, 02, in progress, 03 waiting, 04 postponed, 09 done.

My status values for my tasks

To make those values available in our to do list, select all rows in that column and choose “Validation” from the “Data” menu.

Select “Items from list” from the criteria dropdown list and click the “Select a range” button. While in select mode, navigate to the Lists sheet, select the 5 status values, return to the to do list and save the configuration. Now, you’ll be able to select a status from a dropdown list. That was easy right?

Automated Sorting and Coloring

As a visual being I find it extremely helpful to use colors for certain states a task can have. The following picture shows a sample task list with each state having associated a color. And it’s sorted, btw.

My colorized to do list

Sorting

Let’s start with sorting the to do list. It is possible to trigger a sort on behalf of some arbitrary action, say, on entering or changing a value in column 2. I am doing that for coloring my task list. Every time the status is changed a script colorizes the current row. So, for sorting, you’ll have to do it manually. But don’t be afraid, I have a script for that as well, which allows you to sort a range by simply selecting a custom menu item.

How does it work? All we have to do is to do is insert the following JavaScript methods using Google Docs’ integrated script gallery (see the “Tools” menu):

function onOpen() {
  var s = SpreadsheetApp.getActiveSpreadsheet();
  var menuEntries = [{name: "Sort Selection", functionName: "sortSelection"}];
  s.addMenu("Sort Selection", menuEntries);
}
 
function sortSelection() {
  var rangeToSort = SpreadsheetApp.getActiveRange();
  sortIt(rangeToSort);
}
 
function sortIt(range) {
  range.sort([
    {column: 6, ascending: true},
    {column: 5, ascending: false}
  ]);
}

The method onOpen() creates a new menu in the toolbar only for this spreadsheet that when clicked sorts the current selection. That’s pretty much all there is to it. It is worth mentioning, though, that you have to configure the sortIt() method to allow the script to sort by the correct columns. In my case, column 5 represents the status column and 6 is the due date.

Colorizing Tasks by Status

As with sorting we will have to employ some JavaScript to do the job for us. Unlike the previous approach the colorRow() method will be called on each edit, checking the value in the status column and colorizing the row accordingly.

/**
 * Applies coloring rules to all rows of the active sheet.
 * Called by onOpen().
 */
function colorAll() {
  var sheet = SpreadsheetApp.getActiveSheet();
  var startRow = 2;
  var endRow = sheet.getLastRow();
 
  for (var r = startRow; r

The methods are used for two different scenarios. The first is that we want the to do list to be sorted whenever the spreadsheet is opened (that’s what onOpen() is for). The second scenario handles the case when the status changes (onEdit() is the handler of that event).

These methods have one drawback: once you change the structure of your sheet or the values of your status list you’ll have to adjust the methods to reflect the changes, otherwise it may not work correctly.

Additionally, there seems to be a bug in Google’s scripting engine preventing a more thoughtful design instead of nesting if-else statements, but I was not able to get it to work with anonymous methods, case statements and associative array. If you have a refactored solution, I’d be happy to feature it on this site.

Conclusion

Using Google docs for my to do has been a huge relief. No more worries about syncing to do list to different clients. It’s available every time, everywhere. The JavaScript part is what might get a bit difficult, but once you have set it up successfully you won’t have to touch it very often.

Please feel free to share your thoughts, ideas and improvements in the comment section.

Project managers all over the world are sharing the same fate: they feel the pressure of having to add additional value to the product no matter if it is being intended for the public market or specific customer project. Projects are always vulnerable to be chopped for reasons far beyond the project manager’s control. A new breed of PMs have figured out that certain leadership techniques and market insights have a strong impact to the long-term success of any project.

No matter what approaches and methodologies you adhere to, projects are normally managed operationally or strategically and all that matters is the result it brings to the enterprise (or the customer) and to its position in the market. The combination of operational project management and market insights lead to a holistic strategic approach to project management. It focuses on vision, competitive advantage and adaptability, still embracing the methodologies of traditional project management with the right pinch of added value.

At the fundamental level of strategic project leadership is business strategy which needs to be communicated as a project vision to all stakeholders. That way stakeholders understand the project manager’s commitment to the project. Finally, a vision must be transferred into competitive advantage:

1. Project managers are business leaders – Share the responsibility of building business results with project managers, don’t just let them accomplish a task. Let them be part of the business vision.
2. Focus on projects that have the highest potential to contribute to the overall business strategy. Manage the portfolio according to the long-term competitive advantage of the enterprise or the client. Yet, don’t allow projects that are not aligned with the chosen strategy to fall behind.
3. Identify the competitive advantage of every project (or service) in the portfolio and formulate a project strategy in capturing the marketplace. With strategic project leadership there is no single approach for all projects, instead each demands an adaptive and efficient approach.
4. Communicate the project vision and cultivate a project team that believes in the vision’s energy, excitement, and commitment. People have to believe on a sustained, day-to-day basis about their contribution to the project.

Additionally, to increase chances of success of future projects apply conventional techniques to strategic project leadership like creating a hierarchical plan (what I call the SPOT method: Strategy and spirit > Processes and Organization > Tools) and establish effective project monitoring possibly adjusting existing project quality management techniques to the strategic project leadership approach.

Correctly implemented strategic project leadership can be extremely efficient, but remember that it is all about identifying the product’s competitive advantages, marketing this vision to all stakeholders (and the project team as part of the stakeholders) and the overall strategy for delivering the project.

Information itself is almost useless until it is put into context resulting in what we call knowledge. The main problem with information and knowledge is that the latter is result of information processing which is by nature prone to errors. In order to make sense of all that information we construct stories in our mind trying to make logical and causal connections between the “facts”. Missing parts in the causal chain are subconsciously filled in to make sense for us. It is the way our brain works: things have to make sense and if there is not sufficient information we tend to artificially create causality between possibly unrelated scraps of information. Since we do not know if our story is correct but seem to be perfectly sound there is no need to doubt its correctness. Why? Because most information is not verifiable.

Less Is More

Whenever we read the newspaper or listen to some radio shows we automatically start processing the information and weaving a new story or extending an existing one. Consider the following: the elections are over and the news stations start interviewing party leaders who, on the side of the losers, try to explain why they’ve lost the elections. They come up with semi-intelligent arguments about bad campaign strategies, the failure to address the people’s needs and other excuses, yet, only minutes after the election results have been announced these people believe they know the reasons for the outcome. The same is true for the winning party, of course.

Just ask yourself: how do they know? The reasons for winning and losing an election can be manifold: the bad weather kept people away from the voting booths or they just had a change of mind on election day. We just don’t know, and so do the party leaders but they are convinced that they do. You see the problem?

We now enter stage two: the interviewer asks for an expert opinion. The expert explains in great detail why the election went the way it did adding lots of background information to the conglomeration of so called facts. What happens here is that we consume a great amount of completely unverifiable information that may change our perception of things. On the long run we’d be better off without all the noise since the election result is the only verifiable fact that really matters. Consequently, the more information we have accumulated about this particular topic the less precise is the knowledge of events that took place.

We can draw similar conclusions about such dynamics on a variety of topics, when it comes to gossip about celebrities, for example. We are flooded with random noise, useless information that does not add value to our body of knowledge.

We Don’t Know What We Think We Know

Thompson’s article ends prematurely. The most significant part is the where he refers to the Post-Fact Society, a term introduced by Farhad Manjoo, who, in my opinion, correctly concludes that there exists a

disjunction between truth and proof

in an information society. It is important to distinguish between what we actually know and what we think we know. One reason for the illusion of complete knowledge is that we try to examine past events in order to deduce what has happened, again creating a completely plausible story in our mind by connecting the dots of information. It does not matter if we are talking about events that took place hundreds of years or an hour ago. Since we have not been there, we cannot be sure that the information is accurate. We should always remain skeptic must refrain from taking arbitrary information as truth or even proof for our assumptions and theories.

Concluding Remarks

The more information you give someone the more hypotheses and theories they will formulate along the way and the worse off they will be. They see more noise and mistake it for information.

It is almost impossible to protect us from the mechanisms outlined above. It’s far more dangerous to listen to the radio for five hours a day than to read a weekly newspaper since the noise usually is filtered out over time. At least think about the information you’ve consumed today and evaluate it. How much noise did it carry?

Agile principles have become IT best practices [for software development]

said Scott Ambler, agile practice leader for IBM.

Changes

Talking to analysts, consultants, developers and tool makers, I found that the groundswell of interest in agile practices is changing every aspect of how software is produced, from tools and processes to the roles people play in agile organizations.

Three key conclusions emerged from the talks:

1. Going agile is more difficult than many teams anticipate, largely because it turns the roles of project manager, business analyst, programmer and tester on their heads.
2. No two teams apply agile in the same way. That raises questions about what’s agile and what’s not, and more important, whether a process can be improved by adding one or two agile practices.
3. Even though “agile” means different things to different teams, it’s safe to say that agile today is a far less dogmatic development approach than it was in 2001, when the Manifesto for Agile Software Development put Extreme Programming (XP), Scrum and other methodologies on the map.

Written by a group of believers in the ways of agile, the manifesto sums up principles that guide software development, including individuals and interactions over processes and tools and responding to change over following a plan.

Bend the Rules, Please!

One lesson learned from the early agile days is that rigid adherence to a methodology may not work in the real world, said Eclipse Foundation director of the committer community Bjorn Freeman-Benson:

XP is a strict form of agile, and today no one does all the practices. Insisting that the customer do acceptance testing and other things that XP mandates was too large a leap to make.

The customer — in XP, that’s the intended user of the software — was unwilling to take on the time-consuming role XP prescribes. So, rather than bend XP’s rules, the development team canceled the project. A better approach is adapting the methodology to suit the parties involved. A project manager could have assumed the customer role, extracting information from key stakeholders, he said.

Early projects like that gave agile a bad name. Today agile practitioners are more willing to bend the rules. But many are afraid to use the word agile. As a result, there is some stealth adoption of agile going on.

Going wAgile

One way to define agile development is by what it’s not. Some teams turn to agile practices to dig their way out of failing projects by doing two-week iterations, engaging in frequent, intentional communication, and doing frequent builds.

But that’s not agile development. They are simply getting a little bit iterative to put their projects back on track. Often, the line isn’t so easy to draw. Many of the experts I talked to said it’s not uncommon for development managers to add one or two agile practices, such as daily builds and early testing, to their processes. Is that agile? Some teams that take that approach believe it is. But wAagile—that’s traditional waterfall development with a couple of agile practices thrown in—may be a better way to describe such efforts.

A process becomes agile when one practice leads to another practice. For example: You decide to do continuous integration which means a new build is launched each time new code is checked in. That, in turn, impacts how you interact with users, how often those interactions take place, and how you do test cases.

One thing leads to another: You can’t apply just one part of agile without ultimately applying it everywhere.

The trick is choosing a balanced set of practices, but remembering that you don’t have to choose the exact set that Kent Beck (XP’s inventor) chose.

The Eclipse Foundation practices its own agile development approach. Known as the Eclipse Way, it sets guidelines for the 87 projects that fall under the Eclipse umbrella.

Faith Versus Facts

The experts I talked to were quick to weigh in on what’s agile and what’s not. But curiously, the question of whether agile practices actually produce better software, faster, doesn’t generate as much discussion. It’s as if a lack of faith in traditional software development methods—plagued by late projects, cost overruns and applications that don’t deliver business results—equals a belief in all things agile, despite the absence of data on agile’s impact.

Agile benefits—reduced time-to-market, better quality and improved predictability, among others—are widely recognized by they are not empirically proven. Still, agile shops offer anecdotal evidence that the approach works.

For some developers and managers agile has made the work more innovative, maintainable and predictable. I think it has enabled my development team to focus on what the business needs in ways that weren’t possible with waterfall. If your goal is to produce something people will use, agile is the best way to work.