I don’t want to hazard a guess how many times I’ve complained about the terrible misuse of Excel that I often witness at the hands of over-zealous engineers. However, last time I did this someone kindly pointed out that, except for one glancing blow, I’ve never really done much to remedy this first world problem (in fact, if anything I’ve helped contribute to it!).

A prime example of Excel abuse is the fantastic TCC column spreadsheet. So in an attempt to put my money where my mouth is, I’m going to kick off a regular series of posts where I’ll take you, dear reader, through the process of converting this magnificent monstrosity into a Python application.

That’s right, we’re going to do some programming.

n.b. this guide is going to be written like you’re a windoze user without admin rights, however every tool I suggest has an OS X and Linux version.

Step One: Getting Python

I don’t want to dwell too much on the what or why of Python, as, over this series, I’ll be hopefully do a better job of demonstrating this than a paragraph of computer science terminology could ever do. However, you might as well know upfront that it’s a programming language that is favoured for science and engineering applications by academia; and that it’s named after Monty Python.

At the risk of introducing some upfront confusion, but hopefully saving you some pain in the long run, I’m going to recommend that you install Python by using the distribution “Anaconda“. Python is wonderfully diverse and comes in many varied forms and with a whole variety of optional packages. In order to focus on the programming I’m just going to come straight out and tell you to download Anaconda for Python 3.5 for now:

Download Anaconda for Python 3.5

Make sure when you click through the installer that you opt to Add Anaconda to my PATH environment variable and Register Anaconda as my default Python 3.5 unless you know any better.

Programming as we go

For the last part of this introduction I want to get you comfortable with the way python works, so we can just dive straight into writing some more serious code in the next post.

First open up a command prompt and type python and you’ll be dropped into a ‘python prompt’. From this prompt anything you type will be evaluated when you press the enter button. Type 1 + 1 and press enter. Python will respond with 2. Not massively impressive, I know, but you’ve just written and executed some python! Feel free to try a few more calculations, but when you’re ready type quit() to escape.

Of course, this way of using python has a fairly obvious drawback, the user of your “program” will have to type it all out themselves (which was not unknown in the olden-days). Python allows you to write out all the commands that make up your program in a file, which can then be executed- saving you a having to type everything out every time you want to use it!

I’m going to talk a little bit about where to write code next, but for now just open Notepad and type the following:

print(1 + 1)

I’ll come back to the print() in the next post (although short story long it means that the result of 1 + 1 will be shown). For now save the file as sum.py. Now browse to this new file in the command prompt and type python sum.py. You’ll be rewarded with the number 2. Throughout this series will be writing our code in files and then using the python command to run them.

Programs to Write Code

Programmers have a habit of being weirdly opinionated about the editors you should use to write code. However I think I can say without fear of contradiction that none of them would be sadistic enough to suggest that you should use Notepad. Like with Anaconda, I’m just going to tell you to use Visual Studio Code, unless you think you know better. It’s free, light weight, and known how to colour your Python code so it’s easy to read.

Download Visual Studio Code

There are a lot of more powerful and perhaps more Python centric editors out there (PyCharm being my professional choice), but the majority of them will come with a steeper learning curve, and, for now, I don’t want to teach you how to use a Python editor, but how to do some actual coding.

Now with Python installed and the knowledge of how to literally write some Python we’re armed for part two, coming soon, where we’ll make a start on our TCC spreadsheet replacement.

I already know how to write Python, so this is for all you inquisitive engineers out there- I will answer any questions, either as a comment, by e-mail, or on twitter.

The post Python For Engineers: Part 1 appeared first on Being Brunel.

It’s here! We finally have an Engineering Stack Exchange!

It feels a bit like I’ve been talking about this forever– so it is fantastic to see a community finally form and begin to create something. But now we’ve got it, we have to use it- and prove that engineering is just as, if not more, important than coffee, home brewing and emacs, so that those masters of Stack Exchange will promote us from beta to fully fledged members…

What is it?

The Engineering Stack Exchange is a question and answer website devoted to that wonderful and diverse field that is engineering. It is built on the simple, but powerful, and well proven Stack Exchange platform, which promotes good quality questions and answers through a comprehensive reputation system (by adding a touch of gamification; making the whole process a rewarding, if not addicting, one).

Why Not X

It’s a sorry thing, but when promoting an idea- there’s often a feeling that the success of one thing must come at the expense of another. The three biggest engineering communities out there, that I know of, are the Eng-Tips forums, twitter and reddit; and I’d say that a Stack Exchange of our very own should squeeze in without too much displacement.

Forums are a place for discussion; responses are displayed chronologically, and, with exception of a touch of moderation, there is no real review of submissions. This is fantastic for emulating conversation, asking opinions and talking through recommendations, but its not great for forming coherent collections of knowledge. The format doesn’t lend itself to clearly pairing questions and accepted answers, or easily measuring the authority of contributors.

Reddit and twitter are aggregators; ways of sharing and discussing content. And they’re great for that; I’ve lost count of the amount of interesting stuff I’ve stumbled upon from both sources. While they do provide a rudimentary way of measuring contributions, they are terrible for persistence; with reddit posts being lost after six months and twitter only just making it on a Google search.

Conversely, Stack Exchange actively discourages discussions and calls for subjective recommendations; instead it requires that everything is either a question or an answer (or a comment when either is in need of suggestions and corrections). This means that when you find a question in Stack Exchange, you find the answer clearly marked- and the community that develops exists solely to provide solutions to problems.

What Do I Have To Do?

However the most important thing is to keep heart and try and get as involved as you can- our presence on Stack Exchange is still in its infancy, and there will be some teething troubles. If you want to do more, you can start curating as an editor or moderator; or get involved with the meta site and help shape how the our exchange develops.

So give it a few months, and engineering will have a brilliant new resource to help make us all better, multidisciplinary, professionals.

Join the Engineering Stack Exchange

The post Engineering On Stack Exchange appeared first on Being Brunel.

Around two years ago I wrote a post rhapsodising on the benefits of Stack Exchange, about how it was the best thing in the world and why Civil Engineers should totally have a presence there. It finished with a link to the petition, which needed X amount of signatures to get it off the ground.

It turns out, however, that civils weren’t the only engineering discipline attempting to float this idea. Those few of us who had seen our hopes and dreams of a better future for our metaphorical children banded together on an island of “Engineering”; and like a phoenix from the flames the stack grew to the point where it will now be given a chance…

For those of you who aren’t long term readers or are particularly adverse to following links to previous posts- a Stack Exchange is a Question and Answer site. In fact, for a few disciplines (and software engineering comes to mind here) it is the Question and Answer site.

And why would it be the best thing since sliced bread for Engineers to get their own Stack Exchange?

Well, apart from the amazing potential for knowledge sharing and the growth of a community of people willing to chip-in and answer all those difficult questions- it is also brilliant promotion. It’s hard to imagine anything more accessible than a public site where engineers meet to ask and answer real questions from the profession for those who are curious.

But we’re not safe yet: Before Engineering is granted space on the Stack Exchange, we need to prove that there really is a big enough community out there to kick-off by asking and answering questions and maintain activity during the crucial early stages of the site’s life.

And that’s where you can help. I’m not asking you to devote your life to engineering (especially because you probably already have), but to register your commitment to actually use the site when it enters the beta stage. Let’s face it- who wouldn’t want to?

It’s really easy, just click this button:

The post Engineering Stack Exchange appeared first on Being Brunel.

Thanks to the wonders of word processing I can enjoy a vocabulary significantly larger than the collection of words I can actually spell. Alas, however, a spell-checker can only get you so far and confusing words has become the new marker of a badly written report. So here is the other half of this series picking out the words most likely to catch-out engineers writing reports.

effect or affect?

A confusion so common that Microsoft Word now tries to check for it; the dreaded ‘effect’ or ‘affect’.  As a rule of thumb you can limit yourself to using ‘affect’ only when you want a verb and ‘effect’ when you need a noun. As a quick test, you should be talking about effects (loads), and describing things as affected (structures). In formal language, however, you can use ‘effect’ as a verb, to bring something about as a result; in these cases what you should be effecting is a change.

story or storey?

You probably know the difference between these two words, it’s just a common mistake on last-minute drawings: Authors tell stories and buildings have storeys. In the distant future, however, I will concede that structures made sentient by our continuing desperation for smarter building systems may well have a few stories to share…

alot, alright and atleast?

None of these words are strictly real words; they are all the result of they way people talk. Whilst alot and atleast remain correct only in the realms of YouTube comments, alright has entered the vernacular, albeit reluctantly. This means that you can argue alright is, well, all right to put in your engineering reports; but given the traditionalism of the industry I’d recommend that you avoid it.

discreet or discrete?

Unless they are particularly secretive, loading defined as a number of points is discrete. The former does not really apply to engineering works, which are rarely circumspect or confidential.

shall or will?

I didn’t even know there was a difference between these words until someone pulled me up on it a few years back. Unless you’re being particularly pedantic (imagine; a pedantic engineer…)  it officially doesn’t matter, but if you’re describing actions in the future only you (i.e. “I”) ‘will’, everyone else ‘shall’. Unless you’re being emphatic about things, where then you are the only one who (i.e. “I”) ‘shall’, everyone else “will”.

proscribe or prescribe?

It’s words like these that give the English language a bad name. If I prescribe something I’ll be setting out a rule for your to follow, but if I proscribe something I’ll be forbidding you from doing it. Frankly I would use prescribe and prohibit to avoid confusion (proscribe being the realms of formal language in anycase). Just don’t be surprised if proscribing drinking on site causes some unexpected results…

e.g. and i.e.

Of course, we all took Latin (Estne volumen in toga, an solum tibi libet me videre?), and so we all know that ‘e.g.’ stands for exempli gratia (for the sake of example), whilst ‘i.e.’ stands for id est (that is). With this knowledge inherent from our valuable tutelage in ways of dealing with the return of the Roman Empire, it’s easy to distinguish between these two abbreviations: If you’re giving an example, you need “e.g.”; if you’re providing clarification you need “i.e.”.

The post Confused Engineering Words: Part Two appeared first on Being Brunel.

In fear of being accused of racism towards kettles; engineers are not famed for their proficiency with the written word. This poses a bit of a problem when you consider that 19% of civil engineering is writing reports. So, following from my last key skills post, here is the first of a two part series on a few of the common writing mistakes that the spell checker cannot save you from.

it’s or its?

We can talk about possession and abbreviation, but frankly there’s an easy test for this one: Take out the apostrophe. If the sentence makes sense with “it is” then you want “it’s”, if not, you want “its”. Anyway, you shouldn’t be using contractions in formal reports.

principal or principle?

This one catches me out more than it should, but over time I’ve adopted the following strategy for deciding between them: If there is normally more than one, it’s a principle, if there’s usually only one, it’s a principal. In engineering, typically, we have many principles that we use to design a project, which is likely to have only one, principal, aim…

program or programme?

The wonderful thing about being British is that we get to look down at other English speaking countries for not including arbitrary letters in their words for the sake of etymology. This means that whilst there is no ‘I’ in ‘team’ there is a silent ‘me’ in programme. In short, everything thing to do with computers is a program, everything to do with project management is a programme. Just remember, however, that you can never programme anything; the verb is to program.

stationary or stationery?

I’ve actually only seen this mistake once, but it made me chuckle imaging a bridge covered pencils and rubbers; “stationery” loading. In engineering, however, you can get around ever learning the difference by falling back on ‘static’ and visiting the ‘office supplies’ cupboard.

assure, insure or ensure?

These three get used more interchangeably then they should. If you assure a client, you are (normally verbally) dispelling any doubt. If you ensure a client, you guarantee that you’ll get someone a client. If you insure a client, you promise to protect them against (typically financial) losses. It is much cheaper to assure a client than to insure one; but most will ensure you do the latter.

enquire or inquire?

It doesn’t matter. Most Brits will enquire, most Americans will inquire. Technically the former (think enquiry) is used to ask, whilst the latter (think inquiry) is used to cause a formal investigation.

imply or infer?

If you lived in a Michael Bay film your Dad would take you out with a pigskin and analogously imply a ball for you to infer (until the government came to steal your Transformer). People imply things by suggesting them indirectly; people infer things by deducing what has been implied to them. As an engineer if you find yourself inferring something, you should probably get the client to stop implying what they want and specify it properly- or else you’ll end up arguing about it in arbitration later.

advise or advice and practice or practise?

In defiance of all helpful mnemonics: ‘c’ makes a noun, ‘s’ makes a verb. Of course, once you’ve worked out one, you’ve worked out the other. Personally I remember that ‘c’ is closer to the start of the alphabet than ‘s’, as ‘n’ (for noun) is closer than ‘v’ (for verb)- but I admit it’s no big elephant.

The post Confused Engineering Words: Part One appeared first on Being Brunel.

It’s funny to think that the Eurocodes, which were so cutting-edge when I was at University that I was barely taught about them, actually begun life 12 years before I was born. It’s even stranger when you consider that the second generation will be here in less than six years. It is this next edition, and the huge opportunity we have to influence it now, which I want to bring to your attention.

There are a few things that have already been pencilled in for the next generation. We’ll be able to officially design in Glass, FRP and use membrane structures. We’ll also be able to assess existing structures, and verify the robustness and climate change effects of our designs. On a more structurally specific view, improvement and additions to guidance for bearings, expansion joints, integral and cable-stayed bridges, fatigue, axial loading in composite sections and foot bridge vibration is also planned.

The most important goal for this iteration is to make the Eurocodes easier to use. Aside from a continuing commitment to authors of supporting documentation and training courses, the steering committee will also look for ways to improve clarity and make the documents quicker to navigate. On a technical note this includes distributing the XML versions of the codes; potentially allowing for ‘smarter’ digital versions.

As part of this process the BSI is doing something that (in my experience, at least) is unprecedented: It is actually asking engineers to tell them what they think of the Eurocodes, and how they can be improved. Obviously foreseeing a landslide of “I hate them and everything that changes“, they have limited responses to a pro-forma of six questions:

• Do any clauses require editorial or technical correction?
• Which clauses would benefit from improvements in clarity?
• Where should the scope of the EN be extended?
• Where could the EN be shortened?
• Are there any clauses whose application leads to uneconomic construction?
• Are there any clauses whose application necessitates excessive design effort?

The BSI have given engineers until the 15^th of August to provide feedback as part of the Eurocodes 2014 Systemic Reviews, and I urge anyone who has ever complained or lost hours bewildered using this suite (lit. everyone) to chip-in now and make a difference:

Click Here to Influence the Next Generation of Eurocodes.

The post Influencing The Next Eurocodes appeared first on Being Brunel.

This week I learnt that professionals blogging within the construction industry has become enough of a thing for there to be paid courses on the subject. This can only be a good thing. As I am a professional with a relatively successful blog, I thought a post sharing my experience and lessons learned might well be of interest…

Before I begin though- I honestly believe that if more engineers took the time to blog and share what they’re doing with the world, the profession would be much easier to engage with. So if you want to know more, need any help, or just want to promote what you’re doing- feel free to send me an e-mail.

Rule One

If you’re going to start a blog, do it for yourself. I have received the odd compliment or two, enjoyed the thrill of going viral once or twice, and even been interviewed because of it- but blogging takes so much more than it gives; and if you can’t do it because you enjoy it for what it is, then you’ve set yourself up for a fall.

You also need to decide if you’re going to write as yourself, or anonymously. The latter is much harder, and probably only worth it if you’re going to be doing some whistle-blowing. If you’re being yourself- having a look at your employer’s policy; if they don’t have one, or it’s needlessly restrictive, I’d recommend trying to hammer out something before, or soon after, you start. As a side note, Being Brunel isn’t anonymous, I just didn’t want the focus to be about me as a person.

First Steps

Taking the view that you’ve already decided to start blogging, the next step is to decide what to write about. For me, it was clear that the world had enough prominent engineers exchanging rhetoric without me attempting to join in; so I opted to try a more off-beat tact. As a good rule of thumb, I’d say try and write articles that you would actually enjoy reading.

Once you’ve got a vague notion of what you’re going to write, you’ll need a platform. I unequivocally recommend WordPress, which offers simple and free hosting for your blog; making it quick and easy to start writing. At this point you’re going to have to think of a name. Top tips; keep it short and simple, and- if you’re feeling optimistic about the future, have a look on the likes GoDaddy to make sure that no one else owns www.[your-site-name].com already.

The first post is the hardest. Hypocritically, I’d say that you should avoid starting your blogging career with a post about what you’re doing and why you’re doing it. Do keep it short though- you don’t want to burn out too early. I’d also recommend you just get your head down and write it, leave picking themes, changing the layout, writing an ‘about me’ page and all the other superfluous site-setup tasks for now.

Don’t Stop Believing

I might say it jokingly, but I honestly believe the secret to any success I have has come from making a commitment to write a post once every week. The structure is compulsive; making it much harder to abandon or neglect your blog. If you don’t believe me, check online- the world is full of first-post blogs, or those updated in sporadic ‘new year resolution’ fits of activity, only to be abandoned for another two years.

When it comes to knowing what to write, I tend to just jot down ideas for posts, as and when they come, in the back of my diary; remember, not everything you write need be profound or game-changing. I’ve also learnt not to underestimate the amount of time it takes to write a post; when I started I had visions of doing weekly design guides, but I’ve found these are the sort of things that need a few weeks to pull off. Typically I have two posts on the go at any one time; the one for the week, and the ‘big-one‘ for a few weeks time.

Oddly, I’d also say wait until you’ve written about four posts (that’s a month on my schedule) before you start to tell people about the blog. By then you should have hopefully found a rhythm, a bit of a voice, and a vague idea of where you’re going. Now is the time to maybe pretty-up your layout, find a theme, write a heart-felt “about me” page and all that jazz.

Getting Serious

When it comes to making the world aware that you’re now blogging, I found Facebook helpful in my formative months, then LinkedIn (especially if you target groups), followed finally by Twitter- which requires a more significant investment, but is worth it (if only to see what great work other people are doing) when you’re up and going.

After a few months, once you’ve got a feel for it; it might be worth taking your blog a bit more seriously. Consider buying a domain (www.[your-site-name].com), and self-hosting. Migrating from WordPress.com to your own server is easy to do, and gives you the flexibility to use more professional themes and powerful plugins (honestly, I’m not on commission).

Finally, I thought I’d end with a few “tricks of the trade”: Displaying related posts helps people browsing your site to find other articles that might also interest them; the more advance layouts on Being Brunel are done using shortcodes, which are easy enough to write; and Flickr is a wonderful source of free (Creative Commons) images.

The post Blogging For Engineers appeared first on Being Brunel.

One of the better things about having a blog, is that you can take the time to answer all those questions no one asks, like: “When does Being Brunel get updated?” Well, I’m glad you asked, because as of 2014 I’m switching back from Mondays to the every Thursday routine that I started with. Conveniently this means that, despite how late my Christmas offering was, I’m back to having never missed a week, which, incidentally, is my earth-shattering New Years Resolution for 2014; having failed to achieve none of those I set out for 2013…

It’s on the subject of questions nobody is asking that I’ll be writing about today. That’s right, this post will finally answer that burning query: “But how did you make that wonderful parametric Christmas Tree designer, truly, Tom, you are a God amongst men and should become president of the ICE and IStructE immediately” [ed. actual phrasing may vary.] Think of today as the engineering equivalent of a DVD Special Feature, and not, for example, a somewhat lazy way of putting together a post in a single evening…

But first, if you haven’t already:

Play Being Brunel’s Parametric Christmas

Around about mid-October I had a bit of an introduction to parametric design (of which, I’ll admit now, the Christmas Tree designer isn’t strictly an example of) and then I got distracted making a game (not, in fact, this one). Come Christmas, however, I had nearly given up on trying to find something like the 2012 offering of Santa Loading, when I thought “parametric” + “game” = “Christmas”. And that is how I came to the conclusion that I should waste my spare time making a game about Christmas Trees… (best. origin. story. ever.)

Now I knew what I was doing, the next step was to LEARN ALL THE THINGS!!! Ironically the easiest part of the execution was learning a completely new language (Javascript) and drawing the sky, snow, ice, tree, stick-figure Tom and bewildering interface in the hitherto untried Raphael engine (named after the Ninja Turtle, I’m sure). The difficult bit, perhaps predictably, was attempting to quickly “dip into” the Eurocodes for a bit of indicative design.

If I were trying to make a point through all this, it would be that codified Civil Engineering design is unlike software design; and that is to its detriment. The reason that both Javascript and Raphael were so easy to pick-up was the multitude of solid examples, prolific bloggers and a community that grows its knowledge in accessible ways.

The reason that the Eurocodes aren’t is that, as documentation, they are incomplete (to find an indicative wind loading on, and capacity of, a cylinder of wood took five documents), presented in an archaic form (who needs interlinked documents when you can have PDFs?), and written with the bewildering assumption that you are an expert in the subject and just happen to be glancing at a 100 page manual for a bit of a reminder…

But enough of my ranting. The final, and most unexpected, challenge was balancing the world. It’s hard to come up with a reason why you can’t just build a 6km tall tree with a 6km thick trunk, except that you’d be a muppet for doing so. Of course, the obvious thing to do is associate cost to the trunk and happiness to the height; however this creates a linear solution, so all you need do is maintain the same (working) height to trunk ratio ad infinitum to reach astrophysical levels of happiness. In the end I settled on exponential relationships where the coefficients were functions of the geometry. Whilst not interesting, it at least creates a non-obvious optimum point relationship.

For those of you who can be bothered to poke about in the source code you can actually unlock three different types of wood that didn’t make it to the final game, as well making it a true parametric designer by re-linking the checking method to the geometry update. All those with an inquisitive mind can find the original JavaScript in all it’s Open Source glory on my GitHub:

https://github.com/thomasmichaelwallace/paraTree

See you next Thursday…

The post Behind the Scenes of the Brunel Tree appeared first on Being Brunel.

It seems the whole of this last week has been early starts and overtime; whoever said engineering was relaxing? So today the best I can manage is a recommendation: The Visual Guide to the Eurocodes Supporting Documentation.

This free (to CIS subscribers) PDF not only lists, but includes weblinks directly to the CIS download page for all the following essential Eurocode documents:

• The Eurocode Itself (obviously)
• The UK National Annex (for half of the corrections)
• All the NCCI (for the other half of the corrections)
• Most of the documents cited by the NCCI (for the missing bits)
• A few documents for “Background Reading” (incase you haven’t had enough already…)

Whoever the charitable soul at NBS/CIS is who decided to take pity on us poor engineers and collect together this information should, in my opinion, be made a living saint.

So if you haven’t got it already, check out the Visual Guide to the Eurocodes Supporting Documentation on CIS.

The post The Visual Guide to the Eurocodes appeared first on Being Brunel.

So it seems that all the ‘influencers’ on LinkedIn earn livings by stating the obvious to each other. Jealous of this trend, I’ve put together 7 awesome habits that, by following, will make you into the most dynamic engineering project manager outside of this box!

1. Meet, and Meet Again

There’s no I in team, but there is a me[a/e]t! Touching base (for at least seven hours a day) lets you put out fires before they even start. Empowering your team through high-level collaboration will make sure they’re all singing from the same songsheet, and gives you plenty of facetime for blamestorming any project delays resulting from continuous meetings.

2. Save Time, Cut The Programme

When 110% isn’t enough, a real project manager isn’t afraid to actualise the big picture. Take an ideas shower and right-size (assign half the time quoted) the programme; suddenly that project has taken the late-to-early paradigm shift; and you’re the hero!

3. Know Everything, Even When Know You Nothing

A great project manager is a thought-leader and knows all the issues before  they’ve even entered the loop.  At the end of the day, the key to dynamic collaboration is continuous, unrelenting, proactive initiatives. The best project managers know exactly when to admit their ignorance: never. Yes, you may have employed an engineering firm to design for you, but don’t let that stop you from ignoring them.

4. Dial ‘S’ For Speed

Time and time again I see young project managers who are just too afraid to leverage the power of “Phone 2.0”. When a task has become mission-critical you need complete transparency, and the only way to get team-investment is to call every five minutes to find out if it’s still on the radar.

5. Talk, Without Listening

In any project there will always be stakeholders; all of which will believe their issues to be the most important. To really inspire as a project manager you’ve got to follow that golden thread of connectivity, respond to these challenges and repurpose them into your own win-win outcome- regardless of what anyone else says.

6. Paperwork Is Progress

Let me tell you a story from a friend of mine; Clara. She’d been parachuted in to find a path forward and pull the trigger on a failing project. A quick sense check transferred the knowledge she needed to transition these problems into opportunities. Using measurement-focused platforms and document socialising she was able to establish key performance indicators and fully metric the increasing delays the new paperwork was causing.

7. The Last Minute Is The Best Minute

The best project managers don’t move goal posts- they reinvent them! If you’ve got a wish-list you need to throw each and every opportunity at the wall to see what sticks; and how can you do that before the wall’s built?! By synergizing your projects with last minute change management and scope-bandwidth expanding alterations you’ll be sure to get the best out of your designer.

Disclaimer: If you follow these habits and get fired, it’s not my fault- you simply didn’t have an action plan born from blue-sky thinking…

The post 7 Habits of Dynamic Project Managers appeared first on Being Brunel.