Archive for the ‘Projects’ Category
If you’ve seen anything built with Bootstrap you’ll know that the overall design is just beautiful.
Now, mix in that design mojo with the Popover functionality and you’ll get stunning and user-friendly forms like you’ve never had before. It’s so simple to implement and has such a great impact that I’m actually inclined to call this free end-user value. Read the rest of this entry »
From time to time people seriously ask me “how’d you manage to do that?” or “when do you get the time?”.
My regular answer – which surprisingly surprises people :) – is that I just plan for it and do it.
I treat things like little projects – everything from cooking to events to regular household chores.
You see, everything in life has a critical path, a set of dependencies, some constraints, a desired outcome, a list of available assets, required resources or even liabilities and risks. Sounds familiar? So everything in life can be treated like a project, sketched, planned and executed.
Next, they ask things like “what if something doesn’t go according to plan?” – and I smile. I smile because I’ve never seen anything go according to plan, so I’m always ready for change.
Life is the longest project you’ll be part of and planning for it just makes it a lot easier.
Last week was probably the hardest week of my life and this mindset got me through it. Who knows, maybe sometimes I’ll even write about it.
Objectives help your team to focus on the tasks at hand while not losing sight of the overall outcome that it needs to reach.
A good team is results-oriented, focusing on what it is trying to achieve not what it’s currently doing.
Use this checklist to verify that the objectives defined for your project will help you achieve results and won’t hinder your efforts.
Are the defined objectives clear enough?
Contrary to goals, objectives must be focused and clear. Understandable objectives will drive the team to successful results.
Are the defined objectives SMART?
Do the objectives comply with the SMART criteria:
- Time constrained
Is the number of objectives right (4-6 range)?
There is no right number of project objectives but taking into account the fact that objectives should be known and tracked by the team, a low number (having between 4 and 6 objectives is a good compromise) will make it easier for the team to keep focused on the essential. Remember, the more objectives you have, the harder it will be for your team to keep track of them.
Is there a known and clear context?
The defined objectives must be linked to the overall context. Objectives that do not advance the project (useless objectives) or that are contrary to company strategy (like building a whole new product that competes with one that already exists) should be eliminated or changed. For each objective yourself these questions:
Will achieving this objective advance the project?
Does this objective tie in to the project and company goals?
Does this objective follow the company strategy?
Are the defined objectives known and agreed upon?
It is important that all stakeholders know and agree to the defined objectives. It is very important for project success that the objectives are known and agreed upon by project sponsors and executives.
Can each defined objective be tied to a deliverable?
Think of this as a post-SMART check. If you can pinpoint at least one deliverable that helps you attain an objective you are OK. If you can’t ask yourself this: how are we achieving this objective? If it doesn’t matter, you should remove it from the list.
Does every defined objective have quality criteria specified?
Besides being measurable, each objective should have quality criteria defined, so that both quantitative (are we there yet?) and qualitative (is it the right thing?) parameters can be tracked and accounted for. Getting it right is just as important as getting it done.
I love deadlines. I like the whooshing sound they make as they fly by.
January was a tough month, with a lot of new projects and initiatives that needed pushing and pulling to get up and running, consuming a huge chunk of my time… and most importantly, my energy.
As I realized that work started consuming more and more time… I chose to suspend things like participating in communities, writing this blog, working on my other various projects, so that I can give as much attention as I can to my family and to my full time job activities.
And now I have a huge list of things that I wanted to write, mostly technical, some less technical.
Throughout January I’ve raised my pomodoro usage and through trial and error I’ve found that a 20 minute pomodoro followed by a 10 minute break is a perfect fit for my work requirements.
I am however pushing the rules a little because I’m using the 10 minute break between pomodoros for low-cost activities, like following-up on delegated tasks, quick feedback sessions and having quick coffee-break chats.
Anyway, here’s to February, a small and hopefully, more productive month.
There’s a good piece by Mike Mooney on “the framework myth” that I really like. I like to read it every time I start something new.
I also have a quote on a PostIt on my wall:
Keep it simple.
Keep it low-impact.
Keep it clean.
Put the big guns away.
I thought I’d share it with you, go read it:
Tim Ferris published this really good interview with Daymond John, CEO of FUBU.
Of all the places you’d think that a dev takes his inspiration from, the music/rap apparel industry would be the last. It isn’t! I really admire both of these guys and this interview comes to emphasize that they still have a lot of things to share.
Here are some quotes that are aligned with my beliefs and that express what I feel… probably better than I can:
- “It was incredibly tough, but the passion for the project pushed me through. If your project doesn’t do that for you, well, maybe you need to sit down and revaluate.”
- “Everyone has an idea, but it’s taking those first steps toward turning that idea into a reality that are always the toughest.”
- “If you don’t know how to do something, find someone who does.”
- “Sewing is an ability; manufacturing is a knowledge.” – I see a lot of parallels with this one.. it’s not about sewing at all ;)
Making things that matter is hard, and it’s the way it should be! Nothing beautiful and worthwhile is ever easy!
Some time ago I was talking about the similarities of shaving and product releasing, especially the impact of release frequency on velocity.
Returning to this idea, i realized that,increased releasing or increased deployment frequency has a beneficial effect on the overall velocity and quality of the release or deployment, while also improving team morale.
Because of this, I’ve been trying to create and respect strict deployment schedules, matching every development or bug-fixing iteration, namely(and usually)… every week.
It’s hard at the beginning and the first 3-4 iterations are tough (testing and deployment continues through the night because of inefficient planning and scoping) but after the team gets into the rhythm releasing and deployment becomes a trivial and actually fun activity.
Frequent release and deployment cycles also have a tendency of raising customer trust levels and wining some points for the development team, so release fast, release often, release good… and you’ll constantly get better results.
In Inception, or what you do before you begin I talked about a phase of discovery and acquaintance both for you and for your customer. In “Fraternization, or creating friends and allies” I take that further, describing how genuine collaboration and friendship between you and the customer can bring you closer to delivering a great software product, while creating allies and long-lasting friendships.
It is a known fact in software development that customer involvement in all phases of the project greatly increases the chances of success. Having the customer work together with your team gives them a greater sense of ownership, increases their interest and will ease the way to acceptance.
Customer immersion is not a dirty secret; the acceptance is not eased because they get a greater sense of ownership, it is eased because you are actually doing what they want. While working with the customer’s project team, during long projects, you will undoubtedly start to know them better, especially the team members that tend to interact often with your team. Nurture this interaction, accept them as part of the team, be honest and always respect their opinion. Remember that they know what they want and your job is to help them achieve their objectives.
Having said that, I have to warn you about two things: first, fraternizing only works on long-term projects (I’m talking years… not months) and secondly, it must be genuine. Trying to fake friendship and involvement is a cheap trick that can be easily seen and that will turn them into enemies.
Together from day zero
Spend as much time as you can with the customer’s team at the beginning of the project. It’s that easy!
Even if your customer is on the other side of the world, that is not an excuse – get laptops, get on a plane, work with them. If it’s in their offices that’s even better. I am writing this from my hotel room in Baku, Azerbaijan, after spending the entire day with the customer discussing and planning the start-up of a new phase of a national project.
No!, sending a team of analysts does not qualify as “quality time together”. Prove that you are on the same boat by bringing as many team members from as many disciplines as you can.
Quality time together will help create a bond between your teams and it will put the project on the right track. It will give your team the opportunity to prove that you are the real thing and most importantly it will:
- give you a valuable insight on your customers inner workings
- have a great project start-up together and thoroughly note their expectations
- allow you to adapt to their culture and filter out 80% of the misconceptions at minimum cost
- have your team meet the customer’s team so that in the future, when working together, even on critical incidents they will be able to communicate more effective because of familiarity
- exchange contacts securely and directly – detect and familiarize yourself with those key members that we talked about in Inception, or what you do before you begin
I you run an agile shop, have iteration zero together. Show them you mean business, involve them in the process, immerse them in the design phase, build a macro road-map together and position some stories. Demonstrate what you have achieved together in the first review and then…
Enjoy the fruits of your labor
A key factor of productivity and success, both personal and work related is celebrating.
Celebration and dissemination of success is a key technique that, when used properly and correctly, will advance your project, create long-lasting and successful collaborations, reduce stress and prepare everybody for the next big step.
Celebrating you success together, even small breakthroughs, beyond creating a bond between your team and the customers team also:
- gives an overall sense of good, the “closure” needed to proceed to bigger challenges
- proves that your mission is not impossible and that by working together you can accomplish anything
- proves to the stakeholders that the project is advancing
- bigger success stories are perfect for large scale dissemination, getting the project out of the hidden corner and into the light
You can celebrate together by taking the team out for drinks, having a small in-office party or just by having a time-out and discussing what you have just achieved. It all depends on the size of the achievement.
After the celebration, send an email to the customers team leader, project manager or even general manager stating what a great job their team does and what their contribution was to the achievement. Don’t overdo it and don’t CC or BCC the team, their manager will let them know, in his own way.
Shoot the messenger
Give them a direct channel for communication. If they want to get in touch with you, make it easy for them.
Give them your phone number and always answer. If you really can’t answer when they call, have an internal non-official maximum time of response and stick to it. If you’re doing something else, excuse yourself, answer and tell them that you will call them back as soon as possible.
If they use instant messaging or Skype, get an account and talk directly to them, whenever they need you.
You will be surprised of the long-term effects. When you will need them, and you will, they will also be available for you. Fixing dodgy or unclear issues will be a breeze, by avoiding emails and the incident tracking system you will win time, clarity and in time, friends and allies.
Mutual help and lasting relations
By following this simple set of rules, I have gained friends in every project that I have ever worked on, people who I still interact with and help and that also help me when I need it, be it introductions, references or even the occasional hotel reservation in their city. I enjoy meeting them and I always enjoy working with them.
Some of the topics expressed here will be elaborated further in my The lore of delivering software products series so stay tuned in for more information.
S: (n) origin, origination, inception (an event that is a beginning; a first part or stage of subsequent events)
Inception, the first article in my The lore of delivering software products series presents one of the key phases of a software project, a phase so important and sensitive that it alone may decide the final outcome of the project: success or failure.
This is a phase of discovery, acquaintance and assurance both for you, as a provider and for your customer, which so anxiously awaits the day when he can reap the fruits of his financial and social investment in this new project.
This phase is the one that lets you see if the customer is fully involved in the project and is really ready to go the extra mile with you to see the project delivered; this is the phase that tells you if the customer really cares about the project, the product and the benefits that it will bring to the general end-user population, or if this project is only done just because it should, because the budget is there and because people really need something to do and a project is a good thing to do, over and over again.
All or nothing
As we all know, there’s a mythical ratio that everybody avoids mentioning in project meetings or project briefs, namely “two thirds of all software(system) projects fail”. It’s true, they do, but I’ll let somebody else write the series on project failure.
Now, as we know, failure is a very relative term in the software development and integration world. A project can be successfully implemented and used on a nation-wide level while being a huge failure for the company that implemented it, because the costs were 200% more than the contract value. Eh, they’ll be able to use the good references and maybe, in the future, they’ll learn from their mistakes.
Most software projects fail in this phase, which is a good thing, if you want to fail, this is the best phase to fail in, and there’s a good reason for that.
In this phase, your investment, as a provider, will be minimal and – wait, let me rephrase that – your investment in this phase should be minimized, always. Under no circumstance will you start developing the product or purchasing required hardware, software or services. Nah, wait until you have a solid grasp of the project and until you’ve met the customer.
During this phase, your senses must be alert at all times, during all meetings with the customer and your partners, ready to sense any problems, even before any of them can cause them, because they will. If you feel that, even from the first meetings, the engagement of the customer is not up to the challenge, address this issue. If addressing this issue does not work, prepare a contingency plan… an exit strategy. Who knows, maybe you’ll need it.
If the engagement of your customer and your partners reaches your expectations, the project seems to be on track or it’s steadily getting there, you have a moral responsibility to take this project to delivery… and success, because quitting the project once you have completed this phase you cost you not only financially, but it will also hurt your image.
The real stuff
Enough with the chit-chat, and down to the quick and dirty business. This article is actually about what you should do to ensure that the project has a smooth start and that everything is on track.
What you do, as a service provider, is the most important part of this phase. You are responsible for planning and executing most of the activities of this phase. Most importantly, you are responsible with the engagement of the customer and partners in these activities. If you are not the prime contractor and you see that they’re holding back, your main task is to engage them and to make them realize the importance of this phase.
- Be professional, be polite, never over-commit and under-achieve
- Just as you can, the customer can prepare and execute an exit strategy and find another supplier
The activities and outcomes you must target
In this phase there are some things that must be accomplished just for the sake of it and there are other things that are really important and can decide the fate of the project. Just like in life, the ones that really matter seem to avoid the eye.
Activities and deliverables for this phase are split up into two categories:
1. Important to your customer (will actually make their day happy):
- Interim project plan, or working with them on the project plan. A third of the project should be enough. Remember, we’re talking macro planning, a WBS 3 levels deep. Details spoil the whole thing. You know that you’ll have to deliver the final plan sometimes soon, so why not involve the customer in the process.
- Quality assurance, the magical term stating the fact that the project will be guided by quality and that quality assurance procedures will be part of every activity. You know, like testing, standardized work, proof reading, that sort of thing. Yes – you got that right – proofreading documents. Don’t put it in the plan. Just do it!
- Promotion (dissemination) plan. If it’s a big project they’ll want to show it off. You’ll have to create a visual identity, advertise it on TV, have press conferences and go to international fairs and summits. Who knows, maybe it will increase your business in the vertical, it usually does. When you disseminate, do it by cellebrating your achievements with the customer’s team, and letting everybody know.
- Knowledge transfer, or how the French would put it “transfert de savoir-faire”. You have to do it. I know that vendor lock-in is really sweet, but transferring the know-how to your customer will save you a whole lot on maintenance, technical support, upgrades and it will give them the sense of independence and self determination that they desire internally. This is a real gem, and I’ll talk about it in detail in the future.
2. Really important, even critical for the outcome of the project:
- Prepare your project charter! Even if you only use it internally, this will give your team a perpetual single point of reference for the project vision and objectives. It’s not as hard as it seems if you remember that it should not be very detailed. If you are working with a terms of reference document, extracting your charter from it will save some time.
- Identify the internal apparatus of the customer. This is really important! You have to identify the organizational chart of the customer, in regard to this project, the mirror image of your own organizational structure. The most important positions to identify are: who will oversee delivery, who is the person that will give you access to the end-users (this is really important), who is the main stakeholder, the project owner on behalf of the customer, the one that really cares. Usually, the people that hold the power are not the apparent ones. The project director on behalf of the customer will only sign the delivery if one of his aids will give him the technical and business approval. Find these people, as you will really need them during the project.
- Communications plan. Who you talk to, what will you talk about, how often will the meetings happen. It’s a project buster! Having a good communication plan, accepted and executed by you and the customer will ensure that you’re on the same page, all the time.
-The kick-off.The meeting that says it all. Have your team meat with the customer’s team. Show them what you’ll be doing for them. Do it clearly and slowly. Use graphical means. Don’t scare them away. Include everything on this list, even as bullet items. Get a feeling of the customer’s team. Are they into the project?
All of the things above are coming from a pragmatic perspective – just sharing with you what works – not a project management one. Maybe a full blown project manager will have a few more plans or a few more activities up his sleeve or maybe your project has these activities set in stone, some do. The bottom line is that if you cover all aspects but always keep an eye on what your objectives are for this phase, then you’re on the right track.
Your objectives… achieved
To conclude, your minimal objectives for this phase are:
- Get to know your customer and your partners, make them your friends and allies
- Show your customer that you are professionals and that you are at their disposal
- Have a project plan, at least for the first third of the project
- Identify the internal apparatus of the customer. Identify the people that matter
- Setup a clear and concise communications plan
- Have a kick-off, meet face to face as often as possible
- Never over-promise and under-deliver, especially not in this phase!
If you achieve these objectives, you’ll be on the right track to a sustainable project, where all parties are engaged and willing to give their best to produce a great, usable and long lived software product.
Some of the topics expressed here will be elaborated further in my The lore of delivering software products series so stay tuned in for more information.
The lore of delivering software products is a small series I’m writing about processes and best-practices meant to pave the road to delivering great software products.
Jamie Zawinski, as quoted in “Coders at Work”, elegantly summarizes everything that I’m trying to express:
“At the end of the day, ship the f*cking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”
This is not a series about programming, using a specific framework or development methodology, although it includes bits of everything.This is a series about improving the way you work, focusing on the project at hand and delivering great software on time, on scope and on budget.
This series encompasses the lessons that I’ve learned by repeatedly hitting my head against problems with projects, people, processes and occasionally, my own stubbornness.
Photo by Damon Duncan
Series articles (list may change):
- Inception, or what you do before you begin
- Fraternization, or creating friends and allies
- Fixed scope, or the holy grail of software development
- Dangers, or the risks of the trade
- Genesis, or coming into being
- Shims, or the tools of the trade
- Construction, or getting it done
- Quality, or the other part of construction
- Spells, or handing over the knowledge
- Done, or how “the best is better than good”
- Covenant, or what happens after you’re done
- Phoenix, or rising from the ashes
I’ll try to publish one every week, starting with this week’s article, “Inception, or what you do before you begin“.
Feedback is welcomed, bad feedback even more.