You are here
It's About Time! The Journyx Blog
Aloha! The ocean's roar fills my ears, and a beautiful Kona sunset paints the sky. But me, I'm thinking about mud. Muddy thinking, to be exact. Being educated as a physicist, as I was, has its drawbacks. For one, most people assume we have no marketable skills. Sometimes we are misunderstood. I once was contacted by somebody wanting help with their "aura". Apparently "psychic" and "physics" are pretty close in the dictionary. But the biggest challenge I'm facing these days—and I think it's a result of the extremely rigorous and self-consistent thinking I learned during those years—is a complete lack of tolerance for what I call muddy thinking. People work on low priority items while urgent issues languish. Teams fall apart because no one confronts behaviors that undermine trust. Organizations spend huge amounts of money on a project, then suddenly wonder how they will measure success. These bizarre behaviors may seem like examples of muddy behaviors, but to me they indicate either a brain that has flat-lined or a total lack of clarity about what really matters.
Muddy thinking is jeopardizing far too many people's success, and your project may be getting stuck in some of this mud. Here's my approach to thinking and acting with clarity in order to steer clear of the morass. Regardless of your title, position, or job, you need these three sharp instruments in your professional tool belt to stay out of the mud pit:
1. Personal Values
2. Written, Measurable Goals
3. Priority Lists
Read more at ProjectConnections.
It's a jungle out there, but there are still plenty of ways to keep your integrity in the business world. Here are some previous posts from the Journyx Project Management Blog with advice on how to do so.
A post from Journyx CEO Curt Finch on why your products and services should give added value to customers.
2. Making the Best 'Right' Decision
A CIO article on morality in the decision-making process.
3. Yes, Telling Part of the Truth is Lying
Our Grumpy IT Guy's tirade on false advertising and other shady business practices.
4. Look After Your People in These Tough Times
A PROJECTmagazine article on how to do right by your employees in a bad economy.
Companies that rely on innovation for growth — that view the development of new products and services as their métier — must learn more than most to live with failure. For all the effort put into developing and marketing fresh ideas, many projects, particularly the bold ones, are unlikely to achieve commercial success or emerge as major growth drivers. Indeed, studies have shown that it takes as many as 3,000 raw ideas to result in one commercial success.
But lack of commercial success does not have to be a terrible result. If you keep your disappointments cheap, you can afford a lot of them. First you have to be able to separate the winners from the losers. To do that, Ian C. MacMillan, the Dhirubhai Ambani Professor of Innovation and Entrepreneurship at the Wharton School, and I have created a “barebones” net present value (NPV) calculator (available in our book) that assesses such factors as launch time, ramp-up time, competitive response, total investment, and projected annual costs and sales. This analysis, which can be revisited repeatedly during a project’s development, provides a simple way to compare innovation initiatives in a company. If a project consistently produces a negative NPV, continued funding cannot be justified and a graceful ending is warranted.
We call this process “pruning.” Just as a fruit tree yields more if its old, low-yield branches are trimmed back, so a business intent on growth needs to cut projects that are not promising. The goal is to shift resources from unproductive activities to higher-priority, more attractive opportunities.
Read the rest at strategy+business. Free registration required.
In a previous article titled "Kick-Starting Your Projects - What Should You Know About Defining Scope?" we have already discussed the elicitation of high-level scope requirements that would probably appear in the Project Charter or some other auxiliary scope document. At this stage however we are zeroing-in on the next step, the following iteration of scope definition that happens some time after the sign-off of the project charter but before the technical team members start working on the final designs, blueprints and bills of materials.
Eliciting Detailed Scope: Who Should You Talk To?
A question that gets asked frequently, especially on large and complicated projects is: "Who should I include in scope discussions?" This is a very complicated matter and a good number of projects I have known suffered setbacks in the form of cost overruns and missed deadlines because the right group of people (or even single person) were not consulted properly at the scope definition stage.
The first collective group of primary stakeholders are the clients (aka sponsor), customers and the future users of the product or service you are trying to build.
Clients have the final say in the product scope discussions about what the product does, how it does it and how sophisticated or simple it should be because they are the ones financing the project.
Customers are also important because they (hopefully!) will buy and pay for your product. Alternatively they may ignore it and decide to buy the competitor's product. Therefore it is very important that you understand their real needs.
Read on at ProjectTimes. Free registration required.
We have a saying here at Journyx: "No shelfware." You see, many software companies don't care if their software gets used or not, as long as they get your money. We, however, don't feel that way.
Software is not like a hammer that you buy and put in a toolbox until you need it. It is a living, breathing part of your company, and if it is not being used, at least some of the responsibility lies with the manufacturer.
Our attitude extends to the pricing models that we use for our Software-as-a-Service (SaaS), where staffing firms and others with volatile employee bases can pay for only the number of users who use the software every week. It also extends to the metrics that we use internally to measure ourselves (e.g. what percentage of licensed users are actually entering time regularly?)
Wouldn't it be nice if every business operated this way? Your cell phone bill goes down if you don't use the phone. Your cable bill goes down if you don't watch TV for a month. Your car insurance is connected to how much you drive - your mileage - instead of just how many cars you have. Solutions that are flexible and scalable are the ones to use, especially when cash is low.
- Curt Finch, Journyx CEO
In the middle of a lake is not where I expected to learn a significant workplace lesson, but that kind of environment away from desks and cubicles is what allowed my IT leadership team to face the brutal fact that communication is less about talking and more about understanding.
When I took my leadership team on our regular, two-day offsite last year, I knew that I wanted to focus on the basic but critical issue of communication. That decision came after I met an author who made a career out of helping companies leap from good to great. I started thinking about how that applied to my IT group and me: While I think we're good and we do a lot of things well, I don't think we're great.
My first actions were to look at the daily interactions within my group and then seek feedback from the business. People are never fully happy with the level of communication in any organization but, after my observations and conversations, I realized that if we were to be effective team members and keep the business engaged, we just had to become better communicators.
Read the rest at ComputerWorld.
Optimal performance involves finding the right way for the current situation. The goal is to meet the often conflicting multiple demands that face us. One of those demands is the demand for accurate estimates and rational expectations. Estimating is far from a solved game in most project environments. Making it more difficult are irrational demands for certainty and a lack of effective estimating processes.
In estimating, accurate does not mean 100% assured. After all we are estimating, not divining the future. We expect different degrees of accuracy depending on knowledge of requirements, experience with the tasks at hand, the available resources, among other factors. It is widely accepted in project management circles that early in the life of a project an acceptable estimate might have 50% or more possible variance, while later, after requirements have been well understood and transformed into a design the estimate accuracy may increase to within 10% of the final outcome (assuming that the estimators know what they are doing and the environment is stable). Nevertheless, we find that executives, sales people, clients and project sponsors pressure project managers (PMs) into making definitive estimates well before there is enough information to accurately do so. Project managers often pass the pressure along to team leads and project performers who view the whole estimating effort as a stupid game in which no one wins.
Read more at ProjectTimes. Free registration required.
As Business Finance Magazine puts it, PPM solutions like ProjectXecute are "about getting your house in order -- whether you're talking at the corporate level or the IT level -- so that... you're not spending your time, people, and money on operational things just to keep up with business flow, but you're actually streamlined so that when the business opportunities arise, you can go after them."
This is not the kind of economy in which you should be spending unnecessarily. Some expenses are obvious areas to pare back, but others--those vampire expenses--can be less obvious.
Here are some tips to make your business budget a well-oiled machine... read more
Today's economy is forcing most of us to try to do more with less. One
resource that managers definitely do not have more of is time. Your work week - whatever it is - some- times 60 hours or more - is a finite resource. Time is kind of like land: "They're not making any more of it" So how do you utilize this precious commodity more efficiently? read more
- How do I remove open timesheets prior to inactivating a user?
- What is the best time to schedule reports?
Get the answers to these and other questions in the Journyx Tip Archive.
Unfortunately, some companies out there are guilty of providing prospects with "customer references" from people who are not really customers at all. So what steps can you take to ensure that you'll be learning what you need to learn about the entity you're checking up on? How can you know the reference they've given you is real and not somebody's mother?
Steps for Confirming References:
- Have your potential vendor supply you with a full name, title, company phone number and e-mail address for all of the references that you will be contacting -- at least three per vendor. Do not settle for Hotmail, Gmail or Yahoo e-mail addresses.
- Actually call all the references and talk to them. Most people never do this. It takes time and it is work, but you may be averting wasted money, time and effort for your company.
- Do a Google search to ensure that the reference company is real. Does it match the internet domain name of the e-mail address given to you by your potential vendor?
- Check the company Web site for business model appropriateness. Is this reference company similar to your business? After all, software used by restaurants may not be appropriate for your management consultancy.
- Call the reference company's main number, not the direct number of the person you were given. Is this a real company with a real voice/phone system? Is there an automated company directory? When possible, get a receptionist to confirm the reference executive works there.
- If you have any suspicions that the company isn't real, use Whois Search to see how long their domain name has been around and who created it. You can also match up locales to area codes on Wikipedia in order to ensure that your reference is really where he says he is.
- Curt Finch, Journyx CEO
Every IT project is driven by a business requirement. For an IT project manager, the hard part is translating that business requirement into an end product that fully meets that business need.
It's easy for a project manager to sit in a meeting and listen to what the clients say they need their new system to achieve. But what happens when what the client asks for and what you think they mean are two different things? When your solution misses the mark, you're the one your client will blame, leaving you wide open to a lawsuit.
In fact, lawsuits are always a project management risk because there are so many opportunities for professional liability when designing, programming and implementing IT projects. If the solution you or your team implements results in downtime or a failure of network reach, mission-critical applications, integration, scalability or network performance, your client could claim that you didn't do what was asked of you.
If that claim results in a lawsuit, expect a lot of hassle and expense, especially if you don't have the right IT project manager insurance to protect your business. Beyond avoiding lawsuits, it just makes good business sense to get the job done right the first time to avoid expensive re-work and change orders.
Read more at Project Smart.
In most organizations, project management is practised on an exception basis. We only think of it seriously when the project is in big trouble. The need for project management, and in some cases, even its existence, is acknowledged only when we are squarely faced with the reality that the project is out of control.
Our responses to runaway projects are typical. We rely on the magical power of quick-fixes in the middle of a crisis. Typically, we reorganize the project team, seek a change in the design, bring in a new management tool, or fire the project manager and hope for the best.
We tackle the challenge looking for a "silver bullet" and rely on it with a false sense of confidence, only to find that the cycle repeats itself. Faced with problem projects, management soon realizes that controlling them becomes the primary focus of their efforts, instead of running the business itself.
Implementing quick-fixes in lieu of formal project management is like sending a novice pilot on a flying mission. With little training and experience, the pilot is expected to learn the fundamentals the hard way, in the midst of a crisis, and to fix the problems while the plane is still up in the air! Surely, we cannot succeed with this approach, be it with flying or project management.
Read more at ProjectTimes. Free registration required.
e-Builder is a software company that develops web-based, capital program and project management solutions. The company's flagship product, e-Builder Enterprise, helps facility owner/operators, and the architecture, engineering, and construction companies that serve them address the challenges associated with the planning, design, construction, and operation of complex capital projects. The company recently released version 7 of their product, with new functionality such as the structured workflow engine, a business process automation tool.
Recently, e-Builder was selected for Constructech Magazine's list of 50 Hottest Companies for 2009 and Buildings Magazine's list of Top 100 Products.
Well, in almost all of the past articles of this series of 10, I have focused primarily on the problems, hurdles, and challenges associated with implementing a risk-based process in any organization. In this 9th article, I will stress 5 steps to success that I deem to be essential.
1 – Make sure they get it!
In article #8, I stressed that the support of upper management for the risk-based effort is absolutely critical. I will add here, that such support has to be genuine. I have many times experienced upper management “support” with said management believing that the changes necessitated by embracing a risk-based business process would impact those personnel “down the ladder” and would not make meaningful differences in their everyday responsibilities. This very-wrong interpretation typically accounts for their quick agreement to support the effort (“Great, as long as it is for everyone else and it does not impact me!).
I experienced this situation first hand in Egypt years ago (one of many such experiences). The “Big Manager” on location had called us to Egypt to bring risk-based processes to his exploration/production effort and made, while we were present, great pontifications to the gathered employees regarding just how important it was to embrace the new risk-based process. Of course, probabilistic analysis results, usually, in results expressed as ranges and probabilities (a typical cumulative frequency curve, for example). Later, when speaking with one of the “Big Manager’s” direct reports, that person indicated that when bringing information to the “Big Manager,” you had better not show up with a range of answers – he wanted THE number! Just another example of saying one thing but meaning another. This subject is expanded upon greatly in the book Risk Assessment and Decision Making in Business and Industry – A Practical Guide, 2nd Edition.
The lesson here is that management has to be prepared regarding the impact that a switch to risk-based processes will actually have on them and the way they do business. This leads me to the education aspect of this article.
Read more at PM World Today.
6. Say it, forget it, write it, regret it.
If you write an email where you denigrate and berate someone, there is now written evidence that you did so, and it WILL come up at your review. That said, this is not an implicit suggestion that you go close your coworker's door, roundly and soundly berate them, and leave feeling smug. Rather, what I'm trying to suggest is that you should write down whatever it is you want to say and then leave it sitting for an hour or two. Maybe overnight. If you have a close friend with whom you work, or you're personally close with your boss, you might ask them to review it prior to sending. Let's look at it another way, shall we? You're either right, or you're wrong. They're either right or they're wrong. In most cases it's a combination of all of those. If you're 100% right, you have nothing to lose by waiting to cool off before you send that note, and if you're 100% wrong, you'll thank me later. I can't tell you how many times I've violated this rule (usually directly to my boss) and had to apologize later for acting like such a jackass.
I truly hate enforced socialization, free beer notwithstanding. I loathe it. I would rather have my arm broken in most situations. However, when my sales team hits their numbers for which they've been struggling all quarter, and they invite me to join them in a celebration, how do I look if I turn them down? When the company throws a "company appreciation" thing, and they're (purportedly) trying to appreciate me, how do I look if I don't go? Right. If you go out with them from time to time, if you hang out a few times outside of work hours, you look less like a machine and more like a human. People are more likely to respond positively to someone with whom they've spoken personally than someone who seems a black box to them.
8. Tell them your hopes, your dreams, your fears!
Okay, maybe you don't want to go that far, but have a personal conversation with the people in your office. Get to know their kids' names and their spouses' names. Tell them what you do in your spare time. Become human. Topics to avoid include Star Trek, Star Wars, which of the two is better, fart jokes, sexist comments, and the intricacies of any code you're working on at the time. Listen more than you speak.
9. Document your work
My CEO was telling me about working on computers way-back-when (think "vacuum tubes" -- he's pretty old) and asking a kid sitting next to him, "How did you do that?" The kid responded, "I'm not going to tell you!" For quite some time, IT was a magical kingdom wherein only the wizards (IT folk) could live happily, and we guarded our secrets jealously. This is pretty
common for a new knowledge-based field. Look back at the history of guilds and so forth. That time has long since passed, however, and "job security through obscurity" really needs to go away. Other people must be able to understand what you've done, why you've done it, and how to fix it if you're unavailable. No one thanks a person who leaves a company in an incomprehensible mess. You will gain far more job security by professionally documenting and resolving problems than you will by trying to become indispensable by keeping it in your head.
10. Lighten up
Laugh at jokes, even if they're at your expense - especially when they're at your expense. When making jokes, make JOKES, not insults. Accept jokes at your expense, but never make them at someone else's. Remember, you can choose to make friends at work, or you can decide that some people with whom you work aren't worth your time. Either way, you have to work with them. Be gracious. Be helpful. Be professional. Above all, be polite.
I hope with these few points y'all will see what I'm getting at and lighten up a little bit. Remember, if everyone thinks you're a jerk, and you think everyone's a jerk, it's quite possible that the majority opinion is correct.
Hello again, Gentle Reader. Today I was reading Slashdot as I scarfed down a burger, and I came across a long-standing complaint from a relatively new IT worker.
The title of the post was "How Do IT Guys Get Respect and Not Become BOFHs," and the guy who wrote it seems to be in a bit of a quandary.
This is one of those long-standing "complaints" that IT whiners... err... staffers have, and I gotta tell you, it makes my blood boil. There's a line from one of my favorite movies (Grosse Pointe Blank) where John Cusack says, "If I show up at your door, chances are you did something to bring me there." Similarly, I want to point out to all of my IT brethren, "If people are treating you like something that's stuck to the bottom of their shoe, there's a damned good chance that your own attitude caused it."
This is not to say, of course, that there aren't jerks in the world, and it's certainly not to say that we don't encounter them. The nature of IT is such that if you have one jerk in your company, you are eventually going to have to interact with him or her. Put your best foot forward, and do your job.
On that note, I'd like to offer 10 humble points and pointers for my brethren.
1. You don't know everything; stop acting like it.
You didn't go to law school, graduate school, nursing school, college on an athletic scholarship, paramedic training, screenwriting seminars, business school and the seminary. You might have gone to a couple of those, but you know what? You don't know everything. The fact that you can defragment a hard drive does not give you the right to treat someone else with disrespect because they do not know how to do so. I guarantee in most cases, that person knows more about their job than you do.
2. It's not usually the user's fault if they get infected.
Often I'll hear IT folk complain about having to clean a machine from a virus, and usually derogatory comments about the user are made during this tirade. Alright, guys, really, c'mon. Most infected machines happen that way BY ACCIDENT. When you denigrate a user for something outside their control, you are really only asking them to avoid you in the future, and, trust me, you REALLY want your users coming to you at the FIRST sign of trouble, not after they've been infected for six weeks.
3. If there weren't issues, you probably wouldn't have a job.
IT folk often complain when they have to solve problems that are well within their job descriptions. I've never really understood that. I see it as a 2-pronged situation. First, well, I've got something to do. Not that, in my particular job, I'm usually lacking. I've worked hard enough and long enough that I've entered into a position where it's also my job to be proactive and steer our company through upcoming hurdles prior to encountering them.
IT, however, is by nature a pretty reactionary field. Much of our time is spent reacting to problems. That brings up my second prong. Look, mom, job security! You see, it's the rare company that's going to employ you full-time if they have no problems. My suggestion would be stop complaining and understand that it's your job.
4. They're users, not losers.
This is very similar to point 1, but it's a bit more subtle. The problem is that IT folk who understand subtlety probably don't often make this mistake anyway. You see, by making jokes about your users, by calling them dumb, by bitching about them after work, you're fostering, in your own mind, an Us vs. Them mentality. There's an Eastern philosophy that translates roughly to say-do-think. The idea behind this is that if you say something long enough, and if you start to do things to back up what you say, eventually your brain will believe it, and it will become true. If you constantly refer to your co-workers as idiots, you'll start to do things that reinforce this, and you'll start to believe it consciously and subconsciously. This will not make you welcome at the company picnic.
5. By the way, it's losers, not lusers.
Stop using stupid tech speak. It makes you look, at best, aloof, and at worst, lazy, stupid or geeky. Spell words out properly. Somewhere along the way you were presumably taught things like grammar and spelling, comma-splices and capitalization, alliteration and repetition. Use these things. Communicate professionally. This means using actual words, not 3l33t speak. If you wouldn't write it that way to your grandmother, don't write it that way to anyone else. If you cannot spell, use a spell check utility.
Visit the nearest bookstore and you will find uncountable volumes on team building, hiring, and personnel management. Browse the Internet and you will discover scores of articles, blog entries, and other content devoted to the topic. There is a good reason for this amount of attention to the topic. A leader cannot act alone and is only as good as his team. When we talk about Steve Jobs, Bill Gates or Jack Welch, we mustn’t forget that there are people behind them, a team that supports and enables them.
So, given the abundance of writing on the subject out there, why this article?
The answer is simple: on an average, organizations suck at it — all the books and articles and other knowledge notwithstanding. As a consultant, I see a lot of environments, and the sheer number of teams that have a potential to be absolute stars, but are mediocre at present, is astounding. I would like to inspire the reader and provide some ideas for changing things for the better. I cannot be in every organization all the time to fix the problem, so this is simple way of leveraging the reading audience for maximum result.
What exactly is a winning team?
I believe that every leader should strive to build a team that possesses the following three qualities of greatness:
Effectively achieving set objectives
This is the most basic requirement — getting the job done. The necessary conditions for this are cohesiveness, competence, and accountability of the team.
Read more at TechRepublic.
Here's the hard truth of it: many of the people sponsoring our projects are unqualified to do so - some aren't experienced enough to be effective sponsors, and even if they are, most haven't been taught how to be an effective sponsor, and what being an effective sponsor means.
At their best, many sponsors can be well meaning, but also be less than helpful. At their worst, they can be downright dangerous to you and your project.
So how does this happen? It happens because we have a bad habit of encouraging the accidental sponsor.
Let me be cynical about this - and it won't be for the last time - when I tell you how project sponsorships are 'handed out' in some organizations: when the Senior Executive meets, and they understand - or are dragged into the understanding - that they need to appoint a project sponsor for a major initiative, it's too often a matter of assigning whoever's next: They say, "we need a sponsor, and I sponsored that last IT project thingy - it's your turn!"
Through some misguided respect for arbitrary authority (and putting someone who doesn't know much about projects at the top of the project heap is about as arbitrary as it gets), and by unthinking deference to seniority, organizations and the project managers in them too often make the mistake of thinking that the person or people the executive have appointed as the sponsors for our projects will be, must be, the 'right' sponsor(s) to help make the project a success.
Read the entire article at ProjectTimes. Free registration required.